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Preface 


The  Computer  Resource  Management  Technology  (CRMT)  Program  Office, 
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computer  resources  in  mission-critical  Air  Force  systems. 

The  CRMT  Program  was  initiated  to:  (a)  provide  for  the  transition  of 
computer  system  developments  in  laboratories,  industry,  and  academia  to 
system  program  offices;  (b)  develop  and  apply  software  acquisition  manage¬ 
ment  techniques  to  reduce  life-cycle  costs;  and  (c)  provide  improved  software 
design  tools. 

The  Program  Office  contracted  with  Dynamics  Research  Corporation, 
Andover,  MA,  to  carry  out  the  Automated  Interactive  Simulation  Modeling 
System  (AISIM)  and  User-System  Interface  Design  Guidelines  (USI)  Technolo¬ 
gy  Transfer  project  under  Technical,  Engineering,  and  Management  Support 
Task  Order  80047.  The  project's  primary  goal  was  to  develop  this  prototype 
methodology.  Toward  that  goal,  computer-assisted  instruction  was  developed 
for  AISIM,  and  a  computer-based  job  aid  was  developed  for  the  Design 
Guidelines  for  User-Svstem  Interface  Software;  both  AISIM  and  the  Design 
Guidelines  are  CRMT  Program  Office  products. 

This  project  could  not  have  been  completed  without  the  highly  capable  and 
good-humored  guidance  of  Major  Arthur  G.  Decelles,  Computer  Resource 
Management  Technology  Program  Manager,  and  ZLieutenant  John  S.  Herman, 
Policy  and  Procedure  Guidance  Project  Officer  and  technical  representative  of 
the  contracting  officer  for  this  task.  My  gratitude  to  them. 


AISIM  technical  contributions  made  by  1  Lieutenant  Ann  Kuo,  ESD/MD; 

Donald  Constantine,  The  MITRE  Corporation,  Bedford,  MA;  Lynn  Travassaros, 
Mary  Ann  Vazulak,  and  Susan  Kneeburg,  Technology  Projects  Department, 

Ground  Systems  Group,  Hughes  Aircraft  Company,  Fullerton;  CA,  were  greatly 
appreciated,  as  were  USI  information  and  reviews  provided  by  Monty  Joel, 
ESD/PLEA;  Major  June  Babson,  ESD/XRS;  1  Lieutenant  Tim  Aiken,  ESD/ASE;  Sid 
Smith,  Jane  Mosier,  and  Dick  Bloom,  The  MITRE  Corporation. 

Linda  M.  Evers,  Ed.D. 

Project  Manager 


Section  1.0 

Introduction 


1.1  Purpose 

The  purpose  of  this  document  is  to  describe  the  Electronic  Systems 
Division  (ESD)  prototype  methodology  for  designing  and  developing  computer- 
assisted  instruction  (CAI).  The  prototype  methodology  focuses  on  CAI  for 
mission-critical  computer  resource  (MCCR)  personnel  within  the  Electronic 
Systems  Division,  Systems  Command,  United  States  Air  Force.  Application  of 
this  prototype  methodology  will  support  the  transition  of  MCCR  technology, 
tools,  and  techniques. 

The  ESD  prototype  methodology  is  intended  to  complement  the 
decision-making  process  outlined  in  Air  Training  Command  Pamphlet  50-4, 

The  CAI  Decision  Handbook,  and  to  follow  guidelines  set  forth  in  Air  Force 
Manual  50-2,  Instructional  System  Development.  The  prototype  methodology 
also  describes  CAI-specific  procedures  and  products  as  related  to  AFP  50-58, 
Handbook  for  Designers  of  Instructional  Systems.  MIL-T-29053B(TD),  Military 
Specification  Requirements  for  Training  System  Development,  and 
DOD-STD-2167,  Defense  System  Software  Development.  (You  should  have 
these  four  documents  at  hand  while  carrying  out  the  prototype  methodology.) 


1.2  Scope 

Because  no  two  programs  are  alike,  the  prototype  methodology 
describes  a  generic  model  of  the  steps  involved  in  designing  and  developing 
instruction  for  computer-assisted  delivery.  Given  the  wealth  of  knowledge 
available  on  educational  psychology  and  instructional  design,  a  description  of 
how  to  carry  out  these  steps  would  be  well  beyond  the  scope  of  this  document. 
For  assistance  on  how  to  carry  out  the  methodology,  references  and  a  list  of 
recommended  readings  are  provided  for  each  phase  of  the  model. 

This  document  was  written  as  a  handbook  for  managers  of  the 
Government's  in-house  development  efforts.  It  may  also  serve  as  general 
guidelines  for  a  Government  contractor  to  follow.  The  sponsoring  or  approving 
agency  is  anticipated  to  be  a  Government  office  in  either  case.  Whatever  the 
scenario,  you  must  tailor  the  methodology  to  meet  the  needs  of  your  project. 
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1.3  Foundation 

The  ESD  prototype  methodology  for  CAI  design  and  development  is  built 
on  a  foundation  of  existing  documents.  As  shown  in  Figure  1-1,  the  first  step 
in  the  ESD  approach  to  developing  CAI  calls  for  acquisition  and  review  of 
existing  documentation.  All  relevant  programs  of  instruction,  user's  manuals, 
guidebooks,  technical  manuals,  and  technology  transition  or  implementation 
plans  must  be  reviewed  prior  to  developing  CAI. 

If  CAI  is  being  developed  to  support  a  software  tool  or  other  system, 
the  ideal  time  to  analyze  training  requirements  is  while  the  system  and  its 
supporting  documentation  are  being  designed  and  developed.  This  approach 
is  mandatory  if  training  is  to  be  embedded.  Less  complex  systems  also  benefit 
from  early  analysis  of  training  requirements  because  document  design  and 
contents  can  be  developed  with  an  eye  toward  meeting  those  training 
requirements. 


1.4  Assumptions 

This  document  is  intended  to  complement  ATC  Pamphlet  50-4  but  with 
special  emphasis  on  MCCR  CAI.  Therefore,  similar  assumptions  are  made 
regarding  the  target  audience.  Namely,  the  target  audience  of  this  document 
consists  of  MCCR  personnel  "with  significant  knowledge  of  instruction  and  Air 
Force  instructional  procedures  but  minimal  experience  with  designing  and 
developing  computer-assisted  instruction,"  (ATCP  50-4,  p.  ii). 

As  a  user  of  this  methodology,  you  are  assumed  to  have  performed  ISD 
Steps  1  through  4.4  as  described  in  AFM  50-2  and  AFP  50-58.  You  are  also 
assumed  to  have: 

( 1 )  Read  ATC  Pamphlet  50-4 

(2)  Worked  through  its  decision  aids 

(3)  Concluded  that  CAI  will  meet  your  training  requirements 

The  prototype  methodology  describes  a  generic  model  of  the  steps 
involved  in  designing  and  developing  instruction  for  computer-assisted 
delivery.  Consequently,  it  is  assumed  that  the  methodology  will  be  carefully 
tailored  to  meet  the  instructional  and  delivery-system  needs  of  the  project  at 
hand. 
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figure  1-1.  ESD  Approach  to  Computer-Based  Instruction. 
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1.5  Limitations 

Given  that  the  target  audience  is  MCCR  personnel,  the  ESD  prototype 
methodology  may  not  directly  meet  the  needs  of  other  personnel.  If  the 
prototype  methodology  is  applied  to  other  areas,  it  should  be  adapted 
accordingly. 

No  specific  hardware/software  configurations  are  addressed  herein. 
General  authoring  system  concerns  are  addressed,  but  the  prototype 
methodology  is  not  limited  to  authoring-system  users. 

Detailed  discussions  of  automated  job  aids,  on-line  documentation, 
computer-managed  instruction  (CMI),  and  computer-adaptive  testing  are 
beyond  the  scope  of  this  document.  Recommended  readings  are  listed  where 
relevant. 

This  methodology  is  truly  a  prototype.  As  such,  it  serves  as  a  starting 
place  for  revision  and  refinement.  Advances  in  instructional  technology  and 
CAI  lessons  learned  by  MCCR  personnel  will  be  reflected  in  future  iterations. 
Your  comments  and  suggestions  are  welcome;  please  use  the  form  inside  the 
back  cover  of  this  document. 


1.6  Organization 

The  remainder  of  this  document  is  divided  into  six  sections.  Section  2.0 
presents  an  overview  of  the  five-phase  prototype  methodology.  In  Sections 
3.0  through  7.0,  the  five  phases  are  described  in  greater  detail.  Experiences 
of  two  hypothetical  CAI  development  task  managers.  Lieutenants  Green  and 
Swift,  are  recounted  to  illustrate  certain  concepts  and  techniques. 

The  appendixes  include  references;  recommended  readings;  lists  of  CAI- 
related  periodicals,  organizations,  and  conferences;  sample  storyboard  tem¬ 
plates;  sample  screen  design  standards;  and  Figure  1-3  from  AFP  50-58. 
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Section  2.0 

Overview  of  the  Prototype  Methodology 


The  Electronic  Systems  Division  (ESD)  prototype  methodology  for 
producing  computer-assisted  instructional  (CAI)  systems  consists  of  five 
phases: 


•  Phase  I,  Front-End  Analysis  and  Planning  (Milestone  1) 

•  Phase  II,  Preliminary  Design 

•  Phase  III,  Detailed  Design  (Milestones  2  and  3) 

•  Phase  IV,  Transfer  and  Testing  (Milestone  4) 

•  Phase  V,  Implementation  and  Evaluation  (Milestone  5) 

These  phases  are  essentially  CAI-specific  substeps  of  the  ISD  model  de¬ 
scribed  at  a  high  level  in  AFM  50-2,  Instructional  System  Development,  and  in 
greater  detail  in  AFP  50-58,  Handbook  for  Designers  of  Instructional  Systems. 
Figures  2-1  and  2-2  illustrate  the  five-step  ISD  model  and  the  five-phase  ESD 
prototype  methodology.  Figure  1-3  in  Appendix  G  depicts  the  detailed  flow 
diagram  from  AFP  50-58.  Note  that  four  of  the  five  prototype  methodology 
phases  occur  within  Step  4  (Plan,  Develop,  and  Validate  Instruction)  of  the  ISD 
model. 


ISD  Steps  1  through  4.4  must  first  be  performed  to  a  satisfactory  level 
of  detail  before  initiating  the  phases  outlined  in  this  prototype  methodology. 

Because  CAI  is  a  software  product,  the  prototype  methodology  also 
draws  on  some  of  the  concepts  set  forth  in  DOD-STD  2167,  Defense  System 
Software  Development.  Figure  2-3  depicts  the  six  software  development 
phases  prescribed  in  DOD-STD-2167.  "Tailoring,"  or  adapting  guidelines  to  suit 
the  project  at  hand,  is  a  fundamental  principle  of  2167.  That  principle  applies 
equally  well  to  this  handbook  because  no  two  CAI  systems  have  the  same 
requirements. 


2.1  Phase  I:  Front-End  Analysis  and  Planning  (Milestone  1) 

Phase  I  of  the  prototype  methodology  is  initiated  after  completing  the 
media-selection  process  in  Step  4  of  the  ISD  model.  As  with  any  development 
effort,  front-end  analysis  and  planning  is  critical  to  the  success  of  the  project. 

It  is  difficult  to  know  when  you  have  arrived  at  your  destination  if  you  did 
not  know  where  you  were  going  in  the  first  place. 
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Figure  2-1.  Model  for  Instructional  System  Development. 


0)  0) 

-  o 
O  O 

2? 

CL  O 

^  C 

w  £ 


CNI 

i 

C\l 

0) 

D 

O) 

Li. 


2-3 


c  c 

o  o 


CD 


O  C 

co  o 


CD  »- 


O  O 
(J  U 


CD 

CD 

CO 

TO 

XI 

a 


CD 


D) 

C 


CO 

CD 


a 

CO 

a 


03 

5 


o 

CO 


2  g 

D  O 

a.  Q- 
E  E 
o  o 
o  a 


CO 

CD 

CO 

03 

XI 

a 


c 

o 


o 

co 

o 


c a 

D> 

CD 


C 


O) 

c 


CO 

CD 


<  < 

o  a 

Li.  CL 


TO  TO  TO 

C  *-  —  *- 

o  3  «  3 

•-  a>  -  o  d) 

o  wcr 

C  CT3  >CXJ 

□  O  3  £  o  3 

ll  o  <  a  o  < 


CO 

CO 

CD 

c 


CC  CO  TO 

CC  CD  CD 

H  h  CC 


^r 

CD 

CO 

TO 

XI 

CL 


T3  .tr 

O  C 
CJ  3 


QC 

Q 

O 


TO  C  ^ 

O  O)  0) 

CO  > 
CD  CD 

O  Q  CC 


CO 

CD 

(O 

TO 


T3 

CD 

C 

_ 

CD 

TO 

(O 

CD 

CD 

a. 


Q  Q 


cc 

a 

a. 


TO 

C 

c  c  5 

C  O)  Q) 


CD 


CO  > 


Z  CD  CD 

a  o  cc 


CD 

CO 

TO 

XI 

a 


CM 


TO 

C 


CD 

(O 

TO 

XI 

CL 


E 

Q> 

a 


<o 


CD 

k_ 

TO 

$ 

O 

CO 


c 

CD 


3  >* 
O"  03 
CD  C 
CC  < 


c 

O) 

CO 

CD 

a 


c 

o 


cc 

CO 

CO 


CD 

TO 

o 

TO 

z  5 

5 

o  2 

CD  > 

o 

CL  O 

CO 

CO  cc 

2-4 


Figure  2-3.  The  Six-Phase  DOD-STD-2167  Software  Development  Cycle. 
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Phase  I  begins  with  a  reevaluation  of  the  information  you  gathered  or 
generated  in  Steps  1  through  3  of  the  ISD  model.  This  reevaluation  is 
performed  in  light  of  your  decision  to  include  CAI  in  the  instructional 
approach.  As  shown  in  Figure  2-4,  this  phase  ends  with  Milestone  1 ,  which 
marks  Government  approval  of  a  CAI  Support  Plan. 


2.2  Phase  II:  Preliminary  Design 

In  this  phase,  you  expand  the  detailed  outlines  produced  in  Phase  I. 
The  result  is  a  Preliminary  Design  Report.  This  report  is  a  set  of  rough 
storyboards  that  focuses  on  the  content  and  flow  of  the  courseware  rather 
than  on  the  style  and  format  in  which  the  instruction  will  be  presented.  Phase 
II  contains  no  formal  milestones,  although  the  sponsoring  agency  should 
continue  to  be  provided  visibility  into  the  project  through  weekly  reports  and 
technical  interchange  meetings. 


2.3  Phase  III:  Detailed  Design  (Milestones  2  and  3) 

This  phase  is  where  the  bulk  of  your  development  resources  are 
expended.  Here  you  expand  the  Preliminary  Design  Report  to  a  Draft  Detailed 
Design  Report  and  then  a  Final  Detailed  Design  Report.  Milestone  2  marks 
Government  approval  of  the  Draft  Detailed  Design  Report.  Phase  III  ends  with 
Milestone  3,  which  marks  Government  approval  of  the  Final  Detailed  Design 
Report. 


2.4  Phase  IV:  Transfer  and  Validation  (Milestone  4) 

In  Phase  IV,  you  will  transfer  the  contents  of  the  Final  Detailed  Design 
Report  to  the  authoring  system  you  chose  in  Phase  I.  To  avoid  unpleasant 
surprises  on  the  part  of  your  intended  users,  the  courseware  must  be  tested 
and  debugged  in  this  phase.  It  should  also  be  validated  in  individual  try-outs. 
Phase  IV  ends  with  Milestone  4,  which  marks  Government  acceptance  of  the 
courseware  and  of  ancillary  materials  such  as  the  course  guide  and  the 
instructor’s  manual. 


2.5  Phase  V:  Implementation  and  Evaluation  (Milestone  5) 

Phase  V  corresponds  to  Step  5  of  the  ISD  model.  Finally,  you  are  ready 
to  distribute  the  debugged,  validated  product.  Distribution  might  mean 
mailing  a  magnetic  tape  or  a  set  of  diskettes  and  the  accompanying  course 
materials  to  learners  in  the  Field.  Or,  if  you  are  conducting  an  on-site  program 
or  course,  distribution  might  mean  including  the  courseware  in  your  plan  of 
instruction.  After  distributing  the  product,  you  should  evaluate  the 
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courseware's  effectiveness  as  input  to  future  revision  efforts.  Results  of  your 
evaluation  are  documented  in  the  Recommended  Revisions  Report.  Govern¬ 
ment  acceptance  of  that  report  marks  Milestone  5,  which  completes  your 
courseware  development  effort. 
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Section  3.0 

Phase  I:  Front-End  Analysis  and  Planning 


Before  starting  Phase  I  of  the  Electronic  Systems  Division  (ESD)  CAI 
design  and  development  prototype  methodology,  you  must  first  perform  Steps 
1  through  4.4  of  the  AFP  50-58  ISD  model  to  a  satisfactory  level  of  detail. 
Definition  of  the  term  "satisfactory"  depends  on  the  requirements  of  your 
project. 


Instructional  methods  and  media  selection  issues  arise  as  early  as  Step 
2  (Define  Education/Training  Requirements)  of  the  ISD  model.  Among  other 
topics,  Step  2  addresses  methods  for  acquiring  qualified  personnel  as  well  as 
the  criteria  and  constraints  affecting  method  and  media 
selection. 

If  you  had  a  strong  suspicion  that  computer-assisted  instruction  might 
be  appropriate,  you  would  keep  that  in  mind  while  carrying  out  Step  3 
(Develop  Objectives  and  Tests).  Although  computers  can  be  powerful  test 
administrators,  greater  power  is  obtained  by  spending  more  time  on  item 
design  and  construction.  And  more  time,  of  course,  is  obtained  by  spending 
more  money. 

Media  selection  is  made  formally  in  Step  4  (Plan,  Develop,  and  Validate 
Instruction).  As  stated  in  ATC  Pamphlet  50-4,  The  CAI  Decision  Handbook: 

When  training  requirements  have  been  established  and 
translated  into  appropriate  training  and  instructional  objectives, 
then  step  four  of  the  ISD  model  provides  for  the  planning  of 
how  these  objectives  can  best  be  achieved.  Part  of  this  planning 
process  is  to  select  the  appropriate  medium  and  technique  of 
instructional  delivery,  (p.  1-15). 

If  CAI  still  seemed  to  be  a  feasible  option,  you  would  work  through  the  eight 
decision  aids  in  ATC  Pamphlet  50-4.  (While  that  pamphlet  is  focused  "entirely 
on  the  interactive  instructional  mode  called  CAI"  (p.  1-2),  many  of  the 
questions  posed  on  the  CAI  decision  aids  worksheets  could  also  be  asked  about 
an  automated  job  aid  or  an  on-line  reference  tool.  Decision  Aids  4  through  7 
would  be  especially  helpful  when  considering  computer-assisted  presentations 
other  than  CAI.) 

By  this  point,  you  have  worked  through  the  decision  aids,  concluded 
that  CAI  is  the  medium  of  choice,  and  determined  that  sufficient  resources  are 
available  to  design,  develop,  and  implement  CAI  properly.  You  are  now  ready 
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to  begin  Phase  I  of  the  prototype  methodology.  Figure  3-1  presents  the  eight 
steps  in  Phase  I. 

The  input  for  this  phase  depends  on  why  you  are  developing  a  CAI 
system.  Your  purpose  may  be  to  enhance  an  existing  course,  to  provide 
stand-alone  instruction,  or  to  support  software  users  with  embedded  training, 
among  numerous  other  applications.  Input  could  include: 

•  Program  plan 

•  Program  of  instruction 

•  Course  hand-out  materials 

•  Technology  implementation  plan 

•  User's  manuals 

•  Guidebooks  and  relevant  standards,  regulations,  etc. 

•  Products  of  AFP  50-58  Steps  1  through  4.4 

•  Products  of  decision  aids  in  ATC  Pamphlet  50-2 

As  you  execute  the  following  steps,  keep  in  mind  that  the  output  of  this  phase 
is  the  CAI  Support  Plan,  which  summarizes  the  information  that  you  have 
reviewed  and  revised  in  Steps  1  through  7.  The  remainder  of  this  section 
presents  detailed  descriptions  of  Phase  I’s  eight  steps. 


3.1  Step  1:  Review  Program  Plan 

As  discussed  in  Section  1.3,  the  ESD  prototype  methodology  is  built  on  a 
foundation  of  existing  documentation.  One  of  the  first  documents  to  consult  is 
the  relevant  technology  transition,  or  implementation,  plan  if  available.  A 
typical  transition  plan  identifies  agencies  that  will  benefit  from  task  products, 
provisions  for  distribution  to  those  agencies,  and  expected  operational  and 
support  (including  training)  requirements. 

If  your  CAI  system  is  part  of  the  training  requirements  projected  in  the 
task  description,  you  probably  examined  that  document  prior  to  beginning 
Step  1  of  the  ISD  model.  If  you  are  enhancing  existing  instruction,  you  should 
have  the  relevant  job  task  analysis  to  review. 

Now,  having  completed  Steps  1  through  4.4  of  the  AFP  50-58  ISD  model, 
review  the  task  description  and  any  revisions  to  it.  In  your  review,  consider 
(1 )  the  results  of  those  steps  and  (2)  the  implications  of  using  CAI  to  support 
the  task  product.  As  you  review  the  task  description,  ask  yourself  questions 
such  as: 

Ql:  Are  the  high-level  system  and  instructional  requirements  still  on 
target? 

Q2:  Will  the  tool's  revisions  and  enhancements  schedule  make 
the  cost  of  updating  CAI  unacceptable? 
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Q3:  Does  the  existing  course  need  frequent  revision  to  keep  up 
with  advances  or  policy  changes? 

Q4:  Will  the  cost  of  CA1  development,  distribution,  and  implementation 
exceed  the  projected  equipment  or  funding  requirements? 

Q5:  Did  development  of  the  system  itself  take  a  significantly  different 
course  from  that  anticipated  in  the  task  description? 

You  answered  these  and  similar  questions  during  media  selection.  Reviewing 
your  answers  again  now  will  either  keep  you  on  track  with  the  original  plan  or 
will  alert  you  to  deviations  from  the  plan  that  may  impact  your  CAI  effort. 


3.2  Step  2:  Review  Products  of  ISD  Step  1 

Step  1  of  the  ISD  process  is  titled  "Analyze  System  Requirements."  As 
described  in  Section  1  -3  of  AFM  50-2,  Instructional  System  Development. 

Analyzing  system  requirements  primarily  involves  data 
collection. ...The  product  of  this  step  is  a  definitive  list  of  all  job 
tasks,  the  equipment  or  materials  involved  with  each  task,  the 
conditions  under  which  the  tasks  must  be  performed,  and  the 
work  quality  requirements  that  must  be  met.  For  later  use,  data 
[are]  also  needed  on  frequency  of  performance  of  the  tasks, 
safety  requirements,  criticality,  complexity,  and  the  difficulty  of 
learning  or  teaching,  (p.1-3). 

At  this  point,  you  should  review  the  list  you  produced  for  ISD  Step  1  in 
light  of  your  decision  to  develop  CAI.  As  you  review  the  list,  ask  yourself 
questions  such  as: 

Ql:  Does  infrequent  performance  suggest  that  an  automated  job 
aid  would  be  a  better  solution  than  CAI? 

Q2:  Is  the  list  of  job  tasks  fairly  stable,  or  will  the  basis  of  the  course 
keep  changing,  making  CAI  impractical? 

Q3:  Can  the  job  tasks  be  adequately  supported  with  CAI? 

Q4:  If  simulation  is  your  probable  instructional  approach,  how  critical  is 
fidelity? 

Q5:  Can  the  required  level  of  fidelity  be  achieved  with  CAI? 

Q6:  Given  the  capabilities  of  CAI  authoring  and  management 
systems,  will  you  be  able  to  measure  attainment  of 
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work  quality  requirements? 

Q7:  Does  the  hazardous  nature  of  the  job  make  practice  on  a  computer 
the  best  way  to  meet  safety  requirements? 


You  addressed  questions  of  this  nature  in  filling  out  the  decision  aids  in  ATC 
Pamphlet  50-4.  However,  more  detailed  answers  are  needed  at  this  point. 


3.3  Step  3:  Review  Products  of  ISD  Step  2 

In  carrying  out  Step  2  of  the  ISD  model  (Define  Education/Training 
Requirements),  you  decided  instruction  was  needed  to  acquire  qualified 
personnel.  You  then  determined  who  would  be  trained  and  what  training  they 
would  need,  given  their  present  skills,  knowledges,  and  abilities. 

Review  the  information  you  gathered  for  Step  2  in  light  of  your 
decision  to  develop  CAI: 

Ql:  Does  the  target  audience  include  a  fairly  diverse  group? 

Q2:  If  so,  will  CAI  be  able  to  meet  such  diverse  needs? 

Q3:  Does  the  complexity  of  the  job  tasks  indicate  that  learners  will 
probably  need  individualized  remediation  and  interactive 
reinforcement? 

Q4:  Is  this  a  subject  area  where  few  experienced  users  exist  or  where 
turnover  is  high? 

Q5:  Will  user  safety  be  a  factor? 

Q6:  Will  ease  of  access  to  CAI  for  refresher  purposes  offset  lag  time 
between  training  and  initial  performance? 

Ql:  Is  the  student  population  dispersed  geographically? 

Q8:  Will  on-site  instruction  that  involves  TDY  be  difficult  to  schedule  for 
both  instructors  and  students? 

These  are  only  a  few  of  the  issues  you  need  to  resolve  in  reviewing  the 
products  of  ISD  Step  2.  Other  issues  will  arise  from  the  requirements  of  your 
particular  situation. 
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3.4  Step  4:  Review  Products  of  ISD  Step  3 

The  specific  behavioral  objectives  produced  in  Step  3  of  the  ISD  model 
(Develop  Objectives  and  Tests)  play  a  critical  role  in  developing  any 
instructional  system.  They  constitute  the  road  map  you  will  follow  to  move 
from  describing  the  need  for  instruction  to  having  an  instructional  product 
with  which  to  meet  that  need  effectively. 

The  terrain  you  will  cross  in  developing  CAI  is  significantly  more 
treacherous  than  that  of  traditional  instructional  methods.  Consequently,  the 
course's  behavioral  objectives  must  be  well  thought-out  and  carefully 
phrased.  As  stated  in  Section  2.1,  it's  difficult  to  know  when  you  have  reached 
your  destination  if  you  didn't  know  where  you  were  going  in  the  first  place. 

By  this  point  in  the  prototype  methodology,  you  should  review  the 
products  of  ISD  Step  3  to  determine  how  effectively  CAI  can  meet  the  course 
objectives  and  administer  the  test  items.  You  may  decide  that  CAI  is 
appropriate  for  a  few  of  the  objectives,  but  that  the  remainder  would  be  met 
better  by  other  methods.  Or  you  may  want  to  limit  computer  assistance  to 
administering  and  scoring  test  items.  (The  latter  approach  involves  CMI  and 
computer-adaptive  testing,  which  are  beyond  the  scope  of  this  document.) 

The  purpose  of  this  phase  is  to  prevent  as  many  problems  as  possible. 
Your  review  of  ISD  Step  3's  products  is  the  heart  of  this  preventive  approach. 
Before  beginning  your  review,  it  may  be  helpful  to  put  the  objectives  in  a 
table  such  as  the  instructional  planning  worksheet  in  Figure  1-3  of  AFP  50-58, 
Volume  III,  Objectives  and  Tests.  In  reviewing  the  objectives  generated  in  ISD 
Step  3,  ask  yourself  CAI-specific  questions  such  as: 

Ql:  Could  CAI  adequately  present  the  information  the  student  needs  to 
meet  the  course  objectives  as  stated? 

Q2:  Would  you  have  to  revise  the  objectives  in  order  to  stay  within 
CAI's  limitations? 

Q3:  Do  you  know  CAI's  limitations  well  enough  to  answer  Question  2? 

Q4:  Would  a  few  hours  of  a  CAI  consultant's  services  be  a  good 
investment  at  this  time? 

Q5:  If  you  were  to  revise  the  objectives,  what  impact  would  that  have 
on  the  path  laid  out  in  the  technology  transition  plan? 

Q6:  Would  students  still  be  able  to  meet  work  quality  requirements? 

The  same  questions  must  be  asked  about  the  test  items  constructed  as 
part  of  ISD  Step  3.  Section  4-25  of  AFP  50-58,  Volume  III,  Objectives  and 
Tests,  lists  potential  advantages  of  testing  with  various  media.  Relevant 
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questions  to  ask  yourself  about  computer-assisted  testing  include: 

Q7:  Would  it  be  less  expensive  to  administer  computer-assisted 
testing  than  to  test  with  actual  hardware  or  software? 

Q8:  Would  computer-assisted  testing  increase  student  safety? 

Q9:  Would  the  authoring  system's  answer-judging  capacity  limit  learner 
input  so  that  objectives  attainment  could  not  be  measured? 

The  effect  of  revising  test  items  is  not  as  critical  as  that  of  revising  course 
objectives.  Most  types  of  objective  items  can  be  administered  and  scored  with 
CAI/CMI.  Scoring  subjective,  or  open-ended,  answers  requires  either 
considerable  development  time  or  artificial  intelligence,  which  is  not  yet 
widely  available.  As  noted  in  Section  3.0,  with  CAI,  power  is  time  is  money. 

ISD  Step  3.4  of  AFP  50-58  calls  for  developing  and  administering 
survey  tests  to  determine  "what  students  know  or  can  do  before  receiving 
instruction,"  (Volume  III,  Section  1-3).  Results  of  a  survey  test  can  help  you 
fine-tune  your  description  of  the  target  population  as  well  as  revise  the  course 
training  requirements,  objectives,  and  test  items.  Benefits  of  survey  testing  as 
an  aid  to  course/instructional  material  design  are  also  noted  in  Section  1  -3  of 
AFM  50-2. 

If  no  survey  test  was  administered  in  ISD  Step  3,  giving  one  at  this 
stage  in  the  prototype  methodology  is  advisable.  You  may  have  under¬ 
estimated  the  target  learner’s  incoming  knowledge  and  skills  in  your  earlier 
training  requirements  analysis.  If  so,  your  present  plan  calls  for  developing 
more  instruction  than  the  learner  will  need.  In  view  of  how  much  an  hour  of 
CAI  costs  to  develop,  reducing  your  development  load  by  even  one  or  two 
objectives  would  result  in  significant  cost  avoidance. 


3.5  Step  5:  Review/Revise  Products  of  Step  4.1 

Appendix  G  contains  Figure  1-3  from  AFP  50-58,  Volume  I, 
Introduction.  This  will  be  useful  for  you  to  refer  to  throughout  your  CAI 
system  development.  As  shown  in  that  figure,  ISD  Step  4. 1  consists  of  three 
substeps: 

1 )  4. 1 . 1  Plan  Sequence  of  Instruction 

2)  4. 1 .2  Select  Instructional  Methods 

3)  4. 1 .3  Select  Instructional  Media 


A  high-level  discussion  of  these  three  activities  is  presented  in  Section  5-2  of 
AFM  50-2.  The  following  sections  describe  one  approach  to  reviewing  and 
revising  the  products  of  these  three  substeps. 
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3.5.1  Substep  5.1:  Review/Expand  Products  of  4.1.1 

Sections  3.8,  3.9,  and  3.12  of  MIL-T-29053B(TD),  Military  Specification 
Requirements  for  Training  System  Development,  provide  detailed  discussions 
of  objectives  hierarchies  development.  The  applicable  data  item  description 
(DID)  is  UDI-H-25715,  "Objectives  Hierarchies  Report."  Note  that  MIL-T- 
29053B(TD)  is  targeted  at  upgrading  an  existing  training  program,  although 
many  of  its  prescribed  procedures  are  common  to  any  training  development 
effort. 


Substep  4.1.1,  "Plan  Sequence  of  Instruction,"  is  addressed  in  Sections 
2-3  through  2-10  of  AFP  50-58,  Volume  IV  (Planning.  Developing,  and 
Validating  Instruction).  These  sections  offer  insight  into  how  to  plan  the 
sequence  of  instruction  and  how  to  develop  homogeneous  blocks  of 
instruction. 

The  product  of  ISD  Substep  4.1.1  is  a  set  of  course  objectives  ordered  in 
the  optimal  sequence  and  grouped  in  optimal  increments.  In  other  words,  the 
product  identifies  (1)  how  the  learner  will  progress  from  Point  A  to  Point  Z  in 
a  logical,  instructional^  sound  fashion  and  (2)  what  bite-size  chunks  of 
information  the  learner  will  be  fed  en  route.  In  reviewing  this  product  in 
preparation  for  a  CAI  application,  ask  yourself  questions  such  as: 

Ql:  Are  the  chunks  of  information  so  small  that  they  would 
appear  trivial  as  CAI? 

Q2:  Would  backward  chaining  with  CAI  be  appropriate? 

Q3:  Would  the  authoring  system  unduly  limit  the  learner's  option  to 
choose  his  or  her  own  sequence  of  instruction  within  a  unit  or 
course? 

If  your  decision  to  develop  CAI  remains  firm  at  this  point,  translate  the 
sequenced  and  chunked  objectives  into  a  detailed  outline  for  each  unit  of 
instruction.  These  outlines  are  part  of  the  CAI  Support  Plan  you  will  prepare 
in  Step  9  of  this  phase.  They  also  form  the  basis  for  the  Preliminary  Design 
Report  you  will  prepare  in  Step  3  of  Phase  II. 

3.5.2  Substep  5.2:  Review/Revise  Products  of  4.1.2 

Substep  4.1.2,  "Select  Instructional  Methods,"  is  addressed  at  a  high 
level  in  Section  5-2c  of  AFM  50-2  (see  Table  5-2)  and  at  length  in  Sections 
4-C  and  4-D  of  AFP  50-58,  Volume  IV.  When  you  executed  Substep  4.1.2,  you 
identified  one  or  more  instructional  methods,  or  approaches,  best  suited  to 
convey  the  knowledges  and  skills  at  hand. 
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In  considering  CAI,  you  probably  studied  Section  D  of  ATCP  50-4  and 
worked  through  Decision  Aids  2  (or  3)  and  4  of  that  handbook.  Review  your 
answers  to  those  decision  aids  in  preparation  for  developing  the  CAI  Support 
Plan  in  Step  8  of  this  phase. 

3.5.3  Substep  5.3:  Review/Revise  Products  of  4.1.3 

Substep  4.1.3,  "Select  Instructional  Media,"  is  the  critical  point  for 
determining  what  medium  or  mix  of  media  will  be  most  appropriate  to  convey 
your  instructional  message.  Section  5-2d  of  AFM  50-2  contains  valuable 
guidance  on  the  issue  of  media  selection. 

Among  the  statements  most  pertinent  to  CAI  is  the  following:  "It  does 
not  make  sense  to  select  a  presentation  medium  for  which  adequate 
courseware  cannot  be  developed  and  provided  to  the  student,"  (Section 
5-2d(2)(h)).  Here  the  term  "courseware"  refers  to  "technical  data,  textual 
materials,  and  audiotapes,  slides,  movies,  TV  cassettes,  and  other  audiovisual 
instructional  materials,"  (AFM  50-2,  Attachment  1).  In  view  of  the  generally 
poor  quality  CAI  courseware  being  marketed  to  the  Government  as  well  as  to 
the  public,  prospective  CAI  developers  should  examine  their  instructional 
requirements  and  resources  as  objectively  as  possible  before  making  a  final 
commitment  to  this  complex  medium. 

Chapter  5  of  AFP  50-58,  Volume  IV,  especially  Section  D,  "The  Four-Step 
Media  Analysis  Procedure"  (see  Figure  5-4),  contains  more  information  on 
media  selection.  See  also  Section  3.11  in  MIL-T-29053B(TD). 

A  serious  consideration  for  the  Air  Force  CAI  community  is  the 
proliferation  of  incompatible  delivery  systems.  Section  5-2d(2)(i),  AFM  50-2, 
states  that  "In  general,  it  is  recommended  that  a  courseware  presentation 
format  available  from  only  a  single  manufacturer  not  be  selected. 

Courseware  is  more  likely  to  remain  useful  if  it  can  be  presented  on  a  variety 
of  available  equipment." 

CAI  hardware  and  software  considerations  are  addressed  at  length  in 
ATCP  50-4,  but  continued  attention  needs  to  be  paid  to  the  problem  of 
integration  versus  duplication  of  USAF  CAI  systems.  In  the  operations  arena, 
at  the  HQ  USAF  level,  a  functional  review  of  all  projected  operations  computer- 
based  programs  will  soon  be  established  to  assess  and  manage  the  impact  of 
automation  in  operations  squadrons.  The  purpose  of  this  functional  review 
process  is  to  improve  organizational  coordination  throughout  the  chain  of 
acquisition,  implementation,  and  maintenance. 

Reviews  of  this  nature  may  be  established  in  the  future  for  the 
maintenance  and  systems  arenas.  Their  existence  could  have  a  significant 
effect  on  your  selection  and  use  of  the  computer  as  an  instructional  medium. 
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After  reviewing  the  information  you  gathered  or  generated  for  Substep 
4. 1 .3  and  completing  ATCP  50-4  Decision  Aids  5  and  6,  you  probably  realized 
that  "the  computer  [is]  the  most  complex  of  the  tutorial  media,"  (Section  5-17, 
AFP  50-58,  Volume  IV).  In  reevaluating  your  choice  of  CAI  as  part  of  your 
instructional  system,  ask  yourself  questions  such  as: 

Ql:  Is  a  CAI  system  really  called  for,  or  would  other  media  serve  as 
well? 

Q2:  Can  a  CAI  system  meet  your  graphics  requirements,  or  would 

interactive  video,  video,  slides,  or  some  other  medium  convey  that 
information  more  clearly? 

Q3:  Should  you  develop  and  deliver  an  "adequate"  CAI  system,  or 
would  resources  be  better  expended  on  a  superior  non-CAI 
system? 

If  your  office  cannot  dedicate  the  personnel,  equipment,  facilities,  and  funds 
needed  to  produce,  deliver,  and  maintain  a  satisfactory  CAI  system,  you 
should  focus  on  other  media  that  are  less  complex  but  equally  appropriate. 


3.6  Step  6:  Review  Products  of  ISD  Steps  4.2,  4.3,  and  4.4 

Figure  1-3  of  AFP  50-58,  Volume  I  (Introduction),  shows  that  after 
planning  the  instruction  in  ISD  Step  4.1,  you  are  ready  to  perform  these  steps: 


1)  4.2  Determine  Resource  and  Fund  Requirements 

2)  4.3  Get  Resource/Fund  Requirements  Approved 

3)  4.4  Obtain  Required  Resources  and  Funds 

3.6.1  Step  6.1:  Review  Products  of  ISD  Step  4.2 

ISD  Step  4.2  is  titled  "Determine  Resource  and  Fund  Requirements." 
Unless  your  office  or  group  has  developed  CAI  before,  it  is  time  to  dust  off 
your  crystal  ball.  Estimating  resource  and  fund  requirements  is  never  easy, 
but  CAI  development  presents  more  than  its  share  of  black  holes. 

Section  3-5,  AFM  50-2,  calls  for  a  "preliminary  identification  of  resource 
requirements"  to  be  conducted  in  ISD  Step  2.  Section  5-3  of  that  document 
provides  guidance  for  your  final  determination  of  resource  requirements  and 
costs,  as  does  Section  B,  Chapter  6,  of  AFP  50-58.  See  also  the  list  of 
recommended  readings  at  the  end  of  this  section  of  the  ESD  prototype 
methodology. 
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Decision  Aid  7  of  ATCP  50-4  is  a  cost-estimation  worksheet  that 
addresses  the  costs  associated  with: 

•  Hardware  and  software 

•  Courseware  production 

•  Support  costs 
-Facility 

—Operational  support  personnel 
—System  maintenance 

You  filled  in  this  worksheet  prior  to  beginning  Phase  I.  To  facilitate 
preparation  of  the  CAI  Support  Plan  in  Step  8,  check  your  Figures  again, 
keeping  in  mind  that  computer-related  costs  can  change  drastically  over  a  few 
months. 

3.6.2  Step  6.2:  Review  Products  of  ISD  Steps  4.3  and  4.4 

ISD  Steps  4.3,  "Get  Resource/Fund  Requirements  Approved,"  and  4.4, 
’Obtain  Required  Resources  and  Funds,"  are  closely  tied  to  your  particular 
situation.  By  this  point,  you  are  assumed  to  (1)  have  obtained  commitments 
for  sufficient  resources  and  funds  and  (2)  be  ready  to  proceed  to  Step  7  of  the 
ESD  prototype  methodology. 


3.7  Step  7:  Assign  Development  Team 

Section  II-E  of  ATCP  50-4  describes  four  approaches  to  CAI  design  and 
development.  They  include  the: 

1)  Inspired  programmer-author 

2)  Traditional  development  team 

3)  Computer-supported  development  team 

4)  Computer-guided  author 

The  ESD  prototype  methodology  is  targeted  primarily,  but  not  exclusively,  at 
the  computer-supported  development  team.  Computer-guided  CAI 
development  is  becoming  a  reality  but  will  not  be  widely  available  in  the  near 
future.  In  any  case,  the  developer  or  development  team  needs  a  good 
understanding  of  the  ISD  process. 

Depending  on  the  size  of  the  proposed  instructional  system,  the  CAI 
development  team  may  be  composed  of: 

•  Task  manager  (an  experienced  instructional  designer/developer) 

•  Instructional  designers/developers 

•  Subject-matter  experts  (SME's) 

•  Graphics  designer 

•  Technical  editor 
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•  Instructors 

•  Computer/authoring-system  specialist 

•  Proofreaders 

•  Quality  assurance  testers 

•  Users  (experienced  and  novice) 

Ally  (1985)  reported  that  the  team  members  for  converting  a  240-hour 
lab/lecture  course  into  self-paced,  individualized  CAI  fell  into  six  categories: 

•  Manager 

•  Instructional  designer 

•  Communication  specialist 

•  Content  experts 

•  Computer  specialist 

•  Content  validators 

Table  3-1  presents  the  team  members'  roles.  Ally  also  noted  that  ten 
communication  channels  existed  among  team  members  (see  Figure  3-2).  If 
Ally's  content  validators  are  added,  at  least  12  channels  exist.  You  can  readily 
see  how  communication  problems  might  develop.  Ally  stated  the  following: 

To  perform  their  functions  effectively,  the  team  was  given  a  one- 
week  workshop  on  interpersonal  skills.  All  team  members  took 
the  workshop,  which  provided  them  with  the  skills  to  function 
more  effectively  as  a  team.  In  addition,  the  workshop  gave 
members  a  chance  to  become  better  acquainted  with  each  other, 
which  brought  the  team  closer  together,  (p.  28). 

If  your  team  has  not  worked  together  before,  having  them  participate  in  an 
interpersonal  communications  workshop  might  be  a  good  investment.  Ally's 
group  identified  only  one  major  drawback  to  the  team  approach:  "The  initial 
cost  of  team  formation  is  high,"  (p.  30).  But  one  experienced  team  can  beget 
countless  others  at  a  fraction  of  the  initial  cost. 

Francis  (1979)  emphasized  selecting  team  members  on  the  basis  of  CAI 
development  skills  needed  rather  than  on  roles  or  job  positions  to  fill.  This 
reduces  the  tendency  to  pigeonhole  personnel  and  increases  the  likelihood  of 
diverse  contributions  from  each  member.  That,  in  turn,  prevents  boredom. 

As  Kearsley  (1983)  observed, 

One  of  the  major  flaws  in  the  [development]  stage  of  many  CBT 
projects  is  the  lack  of  attention  given  to  CBT  training  or 
orientation. ...Each  member  of  the  team  should  understand  the 
basic  instructional  model  or  procedures  that  will  be  used  for 
development  and  their  role  in  the  process.. ..It  is  also  critical  that 
team  members  new  to  CBT  be  given  an  understanding  of  the 
capabilties  and  limitations  of  CBT  and  their  system  by  studying 


3-12 


Table  3-1.  Role  of  the  Team  Members 


Team  Member  Major  Responsibilities 


Manager 


1.  Prepare  a  workplan  for  the  Project. 

2.  Create  a  management  information 
system  for  the  Project. 

3.  Assign  tasks  to  team  members. 

4.  Monitor  the  completion  of  tasks. 

5.  Evaluate  completed  tasks  based  on 
quality  and  quantity  measures. 

6.  Report  to  administrators  and  com¬ 
mittees  on  the  progress  of  the 
Project 

7.  Write  final  and  interim  reports  on 
the  Project. 

8.  Share  expertise  with  other  team 
members. 


Instructional  I.  Develop  a  detailed  Instructional  De- 
Designer  sign  model  for  courseware  develop¬ 

ment. 

2.  Tram  content  experts  to  use  the 
Instructional  Design  model  to  de¬ 
sign  the  courseware  for  the  technol 
ogies 

3.  Train  instructors  to  use  the  instruc¬ 
tional  technologies. 

4.  Tram  students  to  use  the  instruc¬ 
tional  technologies. 

5.  Script  lessons  for  computer-assisted 
instruction. 

6.  Coordinate  the  production  of  the 
learning  materials. 


Team  Member 

Major  Responsibilities 

( continued ) 

7.  Evaluate  and  revise  learning  materi¬ 
als, 

8.  Coordinate  the  content  validation 
process. 

Communication 

Specialist 

1.  Design  a  format  for  print  materials 
and  training  manuals. 

2.  Proofread  all  manuals  for  *VP°* 
graphical  errors,  readability,  and 
clarity. 

3  Coordinate  the  public  relations  of 
the  Projecl. 

Content 

E\perts 

I  Produce  courseware  Using  the  In¬ 
structional  Design  model. 

2.  Revise  courseware  as  recommended 
by  the  content  validators,  the  In¬ 
structional  Designer,  and  the  Com¬ 
munication  Specialist. 

Computer 
Special  i si 

1  Coordinate  the  installation  of  the 
computer  hardware  and  software. 

2.  Supervise  computer  programmers. 

3.  Establish  the  standards  for  comput¬ 
er-assisted  instruction. 

Content 

Validators 

1.  Review  developed  courseware. 

2.  Assist  the  content  experts  in  mak¬ 
ing  decisions  on  the  content  related 
problems. 
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examples  of  courseware  and,  preferably,  actually  taking  CBT 
courses,  (p.  126). 

MIL-T-29053B(TD)  emphasizes  SME  training  in  every  step  of  the  ISD  process. 
See  Sections  3. 4. 1.3  ("SME  training  for  operator  task  listings  development") 
and  3.12.6  ("SME  training  for  syllabi  development")  for  examples. 


The  graphics  designer's  skills  will  help  you  avoid  creating  a  text-heavy 
electronic  page-turner.  The  technical  editor  and  his  or  her  legion  of  proof¬ 
readers  will  ensure  that  on-line  and  hardcopy  text  is  concise,  unambiguous, 
and  free  of  grammatical  and  typographical  errors. 

Perhaps  the  most  important  contribution  is  made  by  the  subject-matter 
expert  and/or  instructor.  A  reasonable  percentage  of  this  person's  time  must 
be  committed  to  the  team.  The  commitment  should  be  in  writing  from  the 
appropriate  office,  even  if  it  is  your  own  office. 

Finally,  the  CAI  task  manager  resembles  a  squadron  leader  preparing 
for  a  skirmish  with  a  wiley  opponent:  there  is  too  much  work  and  too  much 
uncertainty  to  ever  make  it  alone.  The  assignment  of  your  development  team 
and  your  ability  to  lead  that  team  are  obviously  crucial  to  the  project's 
successful  completion.  Try  not  to  underestimate  the  former  or  overestimate 
the  latter. 


3.8  Step  8:  Prepare  CAI  Support  Plan 

The  treacherous  terrain  of  CAI  development  mandates  your  having  a 
clear,  detailed  map  to  follow.  If  you  are  under  contract,  the  statement  of  work 
was  your  starting  point.  You  will  probably  sketch  in  more  detail  through  the 
minutes  of  technical  interchange  meetings  and  status  reviews. 

Before  stepping  off  into  the  CAI  design  process,  which  often  bears  a 
strong  resemblance  to  quicksand,  prepare  a  detailed  CAI  Support  Plan.  The 
plan  should  contain  at  least  three  sections. 

Section  1  documents  the  information  that  you  have  gathered, 
generated,  and  reviewed  so  far  in  ISD  Steps  1  through  4.4  and  ESD  Prototype 
Methodology  Phase  I.  Include  (or  summarize  where  possible)  the  results  of: 

•  ISD  Step  1:  System  requirements  analysis 

•  ISD  Step  2:  Instructional  requirements  definition,  including  a 

description  of  target  learner  characteristics 
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•  ISD  Step  3:  Course  objectives,  with  the  option  of  including  the  test 

items  in  an  appendix 

•  ISD  Step  4:  Detailed  unit  outlines,  instructional  method  and  media 

selections,  and  development  team  member  assignments 

Having  documented  past  decisions  and  products  in  Section  1,  Section  2 
is  a  straightforward  management  plan  for  carrying  out  the  rest  of  the  ESD 
prototype  methodology.  M1L-T-29053B(TD)  sets  forth  the  requirement  for  a 
training  development  support  plan  (TDSP).  This  plan,  which  is  founded  on 
results  obtained  from  ISD  Steps  1  and  2,  forms  "the  basis  for  effective  project 
procurement  and  management,"  with  its  goal  being  "to  arrive  at  a  method  for 
achieving  project  goals  (both  technical  and  managerial)  that  is  objective  and 
cost-effective  for  the  government,"  (Sections  3.1  and  3.2). 

The  TDSP  includes: 

•Project  objectives 

•Roles  and  responsibilities 

•Program  phasing  and  procurement  strategies 

•Coordination  of  the  ISD  tasks  within  each  of  the  program  phases 

•Schedules  and  milestones 

•Resource  estimates  (contractor  as  well  as  Air  Force) 

•Any  special  planning  requirements 

No  doubt  you  had  determined  many  of  these  earlier,  at  least  at  a  high 
level,  for  funds  justification.  Now,  having  completed  Phase  I,  you  should  have 
a  much  more  realistic  handle  on  schedules  and  milestones,  resource  estimates, 
and  any  special  planning  requirements  such  as  adoption  of  pending  policy 
changes. 

Section  3  of  the  CAI  Support  plan  concerns  the  future  of  your  completed 
CA1  system.  Although  the  TDSP  addresses  procurement  strategies,  attention 
also  needs  to  be  paid  to  the  transition  and  implementation  processes.  Long¬ 
term  support  requires  a  significant  commitment  of  resources  by  a  designated 
agency  (Weischadle  and  Weischadle,  1985).  This  long-term  support  is  critical 
for  the  Air  Force  due  to  the  high  turnover  rate  of  personnel;  technology  is 
easily  lost  when  its  local  proponent  is  reassigned. 

Points  to  consider  in  finalizing  the  CAI  Support  Plan  include: 

•  If  you  are  enhancing  an  existing  course,  provide  a  high-level 
description  of  the  overall  instructional  strategy  for  the  course  and 

identify  where  the  CAI  system  will  fit  into  that  strategy. 

•  If  you  are  developing  instruction  to  support  a  new  system  or 

technique,  provide  a  high-level  description  of  the  transition 
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strategy  for  the  system  or  technique  and  identify  where  the  CAI 
system  will  fit  into  that  strategy. 

•  Identify  the  student  hours,  instructor  contact  hours,  equipment, 

maintenance,  content  updating,  facilities,  and  other  resources  the  CAI 
system  will  require  throughout  the  remainder  of  its  life  cycle. 

•  Identify  the  office  that  will  be  responsible  for  providing  those 

resources  on  a  continuing  basis,  making  sure  that  the  identified 
office  already  has  agreed  to  or  is  aware  of  its  responsibility. 


3.9  Milestone  1:  Government  Approval  of  the  CAI  Support  Plan 

The  primary  product  of  Phase  I  is  the  CAI  Support  Plan.  Approval  of 
this  plan  ensures  that  the  interested  parties  have  roughly  equivalent 
understandings  of: 

•  Decisions/products  to  date 

•  What  topics  the  CAI  system  will  cover 

•  How  the  project  will  proceed  from  this  point 

•  What  resources  the  CAI  system  will  require  for  the  remainder  of 
its  life  cycle 

Milestone  1  is  the  first  of  five  in  the  ESD  prototype  methodology.  Each 
marks  a  critical  point  in  the  design,  development,  acceptance,  and 
implementation  of  your  CAI  system.  One  way  to  manage  these  critical  points 
is  to: 

1)  Distribute  the  product  (in  this  case,  the  CAI  Support  Plan)  to 
concerned  personnel  for  a  21 -day  review  period 

2)  Examine  their  comments  and  write  a  report  summarizing  your 
reactions  and  proposed  solutions 

3)  Distribute  the  report  for  a  ten-day  review  period 

4)  Hold  a  status  review  meeting  to  clarify  everyone’s  understanding  and 
to  resolve  any  remaining  differences 

5)  Document  the  status  review  in  the  form  of  meeting  minutes 

6)  Distribute  the  minutes  to  all  concerned  personnel 


The  phrase  "CAI  power  is  time  is  money"  can  be  abbreviated  to  "Time  is 
money”  here.  In  order  to  keep  your  project  on  schedule  and  within  budget,  it 
is  imperative  that  milestones  be  reached  and  passed  in  a  timely  fashion. 

Because  the  biggest  obstacle  (outside  the  development  team)  to  this  is  usually 
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the  reviewers'  turnaround-or  lack  thereof—you  must  facilitate  their  partici¬ 
pation. 


Facilitation  may  involve  sending  them  a  series  of  memos  as  the  review 
period  approaches;  including  a  self-addressed,  stamped  envelope  with  the 
materials  to  be  reviewed;  or  meeting  with  each  reviewer  to  pick  up  a  copy  of 
his  or  her  comments  and  informally  discuss  the  project.  You  will  be  able  to 
judge  what  future  facilitative  efforts  will  be  called  for  after  you  pass 
Milestone  1. 
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Phase  II:  Preliminary  Design 


Thus  far  in  your  instructional  system  development  effort,  you  have 
completed  Steps  1, 2,  3,  4.1.1,  and  4.1.2  of  the  detailed  ISD  model  depicted  in 
AFP  50-58  (see  Appendix  G).  You  have  worked  through  ATCP  50-4's  eight 
decision  aids  in  executing  Step  4.1.3  of  the  detailed  ISD  model  and  have 
concluded  that  CAI  will  form  at  least  part  of  your  instructional  package. 

In  completing  Phase  I  of  the  prototype  methodology,  you  reviewed  and 
revised  (1)  the  products  of  AFP  50-58  Steps  1  through  4.4  and  (2)  your 
answers  to  the  decision  aids  in  ATCP  50-4,  especially  those  concerning 
resource  requirements.  The  end  product  was  a  CAI  Support  Plan,  Government 
approval  of  which  constitutes  Milestone  1 . 

Now  you  are  ready  to  begin  the  CAI  preliminary  design  process,  Phase 
II  of  the  prototype  methodology.  Figure  4-1  presents  the  eight  steps  of  Phase 
II.  Note  that  four  of  the  eight  are  carried  out  in  parallel. 


4.1  Step  1:  Assemble  Development  Team 

Up  to  this  point,  if  you  are  the  CAI  task  manager,  you  may  have  worked 
alone,  conferring  with  concerned  agencies,  instructors,  course  alumni,  target 
learners,  subject-matter  experts,  CAI  consultants,  and  others  as  needed.  Phase 
II,  however,  requires  participation  of  the  CAI  development  team  you 
identified  in  Step  7  of  Phase  I. 

The  design  work  you  accomplish  in  this  phase  may  be  the  result  of  a 
demanding  and  often  difficult  group  problem-solving  effort.  The  degree  of 
participation  the  task  manager  permits  his  or  her  team  to  have  in  the 
decision-making  process  will  determine  the  amount  of  time  and  energy 
expended  on  group  problem-solving.  If  team  members  have  the  proper 
professional  qualifications,  then  encouraging  their  participation  and 
constructive  feedback  should  result  in  a  superior  instructional  product. 

Management  approaches  to  CAI  development  or  any  other  project  can 
rarely  be  characterized  as  either  directive  or  facilitative.  Instead,  the  task 
manager  must  adapt  his  or  her  approach  to  each  day's  demands.  While  a 
discussion  of  management  approach  is  beyond  the  scope  of  this  document,  do 
not  underestimate  the  criticality  of  the  issue. 
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Figure  4-1.  Phase  II:  Preliminary  Design. 
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According  to  Heffeman  (1985), 

...the  traditional  software  development  life-cycle  model  identifies 
discrete  events  and  phases,  the  logical  relationships  between  data 
products,  the  scheduled  reviews  and  project  milestones,  and  the  logical 
sequence  and  progression  of  the  project  through  these  phases.  In 
reality,  software  projects  are  characterized  by  constant  unforeseen 
changes  in  requirements  and  technical  assumptions,  causing  a  ripple 
effect  of  changes  throughout  other  interrelated  tasks,  (p.  61 ). 

Heffeman  quotes  author  Michael  Evans  as  saying,  "Control  over  this  process 
and  consistency  between  the  data  products  that  pass  from  phase  to  phase  is 
the  critical  component  of  the  software  project  infrastructure."  The  infra¬ 
structure  is  the  "set  of  management  practices  and  methods  used  to  integrate 
all  the  components  of  the  project  together,"  (p.  61). 

The  CAI  task  manager  is  responsible  for  maintaining  a  continuously 
revised,  mental  status  report  on  all  facets  of  the  project.  Here,  the  task 
manager  is  truly  a  knowledge  engineer  whose  mental  expert  system  and 
ability  to  respond  to  those  "constant  unforeseen  changes"  ensures  a  smoothly 
functioning  instructional  system.  As  Evans  concluded. 

What  is  most  important  to  software  quality  and  project 
productivity.. .is  not  the  individual  pieces  that  make  up  the 
project.  Rather,  it  is  the  edges  or  interfaces  between  related 
project  segments.  All  data  developed  must  be  traced  to  a 
changing  set  of  requirements,  and  the  data  products  are  not 
really  complete  until  the  end  of  the  project,  (p.  61). 


4.2  Step  2:  Develop  Unit  Logic  Flow  Charts 

As  stated  above,  the  purpose  of  the  PDR  is  to  sketch  a  visual  outline  of 
storyboard  and  ancillary  material  logic  flow  and  content  for  internal  review 
and  revision.  Your  approach  this  task  depends  a  great  deal  on  available 
materials.  If  you  are  revising  or  enhancing  an  existing  course,  you  will  have  a 
much  different  starting  place  than  if  you  are  developing  instruction  to  support 
a  new  system.  In  either  case,  you  must  first  review  all  available  materials. 

This  review  is  criticial  for  helping  you  to  avoid  re-inventing  the  wheel. 

4.2.1  Step  2.1:  Review  Existing  Materials 

Step  4.5.1  of  the  APT  50-58  ISD  activities  and  decisions  flow  chart  calls 
for  the  instructional  designer  to  "survey  existing  materials  for  suitability,"  (see 
Appendix  G).  You  began  this  activity  in  1 .4.1,  1.4.1 1,  or  1.4.13,  when  you 
conducted  your  initial  system  description/performance  data  collection  effort. 
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You  reviewed  those  data  for  AFP  50-58  Step  3  and  again  for  Step  4.1, 
especially  4.1.1  (Plan  Sequence  of  Instruction). 


With  the  course  objectives  from  AFP  50-58  Step  3.2,  the  detailed 
outlines  from  Phase  I,  and  your  subject-matter  expert  at  hand,  review  all 
existing  materials  again  now  as  you  prepare  to  develop  the  Preliminary  Design 
Report.  Ask  yourself  questions  such  as: 

Ql:  Which  materials  address  information  learners  will  need  in  order  to 
meet  the  objectives? 

Q2:  How  easily  will  you  be  able  to  adapt  materials  to  the  instructional 
methods  you  identified  in  AFP  50-58  Step  4.1.2  (Select  Instructional 
Methods)? 

Q3:  Are  those  materials  written  as  a  user's  reference  manual  or  as  an 
instructional  tool? 

Q4:  If  the  document  is  a  user’s  reference  manual,  what  new  materials 
will  have  to  be  written  to  build  an  instructional  foundation  for 
novices? 

Q5:  Will  the  SME  be  available  to  support  development  of  new  materials 
at  this  time? 

Once  you  have  answered  these  and  similar  questions,  you  should  have 
the  clearest  idea  so  far  of  how  you  will  flesh  out  the  detailed  outlines  from 
Phase  I.  You  are  now  ready  to  sketch  logic  flow  charts  for  each  unit  of  CAI. 


4.2.2  Step  2.2:  Develop  Unit  Logic  Flow  Charts 

The  preliminary  logic  flow  charts  you  develop  in  this  substep  are  much 
like  those  for  any  type  of  system  analysis  and  documentation.  Besides  helping 
you  define  unit  logic  flow  and  contents,  the  product  of  this  activity  can  serve 
as  your  first  cut  at  a  high-level  branching  scheme  (see  Chapters  2,  3,  5,  and  6 
of  AFP  50-58,  Volume  VI,  for  explanations  and  examples  of  four  branching 
schemes).  It  may  help  to  think  of  logic  flow  charts  as  the  course  skeleton, 
which  you  will  flesh  out  in  Step  3  of  this  phase. 

Reviewing  the  common-element  objectives,  criterion  objectives,  and 
subobjectives  you  wrote  for  AFP  50-58  Step  3.2  would  be  helpful  at  this  point. 
Section  3-2  of  AFP  50-58,  Volume  III,  discusses  common-element  objectives 
in  detail.  To  reduce  unnecessary  redundancy,  you  need  to  identify  which 
objectives  and  their  supporting  instructional  materials  will  be  common  across 
two  or  more  units.  The  preliminary  logic  flow  chart  is  a  graphic  reminder  of 
where  that  relationship  exists  across  units. 
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For  example,  in  executing  AFP  50-58  Step  3.2,  Lt  Green  had  determined 
that  Common -Element  Objective  4.1  would  be  covered  in  Unit  2.  The  learner's 
approach  he  wrote  for  the  course  called  for  successful  completion  of  each  unit 
in  sequence.  This  enabled  him  to  focus  on  new  objectives  in  Unit  3  rather  than 
covering  Common-Element  Objective  4.1  again.  Now,  to  complete  this  substep 
of  Phase  II,  he  reflects  the  relationship  in  the  preliminary  logic  flow  chart. 


4.3  Step  3:  Develop  Preliminary  Design  Report 

Given  the  foundation  established  with  the  CAI  Support  Plan  from  Phase 
I,  this  step  consists  of  expanding  the  detailed  unit  outlines  to  a  Preliminary 
Design  Report  (PDR),  which  is  the  major  product  of  this  phase.  The  Preliminary 
Design  Report  is  a  high-level  definition  of  unit  logic  flow  and  content.  The 
"report"  is  actually  a  set  of  rough  storyboards  for  internal  review  and  revision. 
The  PDR  gives  your  CAI  development  team  the  chance  to  (1)  make  sure 
everyone  is  on  the  same  wavelength  and  (2)  offer  creative  alternatives  to  the 
proposed  approach. 


The  Preliminary  Design  Report  is  the  bridge  between  the  CAI  Support 
Plan  and  the  Draft  Detailed  Design  Report.  As  such,  it  builds  on  the  skeleton 
you  constructed  with  the  unit  logic  flow  charts  in  Step  2.2  of  this  phase. 

The  objectives  of  this  step  are  to  (1)  create  rough  storyboards  that 
reflect  the  course  logic  flow  and  contents  and  (2)  do  so  as  quickly  as  possible. 
Writing  text  in  a  bulleted  format: 

•  AISIM  has  five  main  user  interfaces 

•  Each  user  interface  is  accessible  from  AISIM  READY 

or  as  a  telegram: 

2167  =  document  to  be  tailored  to 
each  acquisition’s  requirements 

» 

will  speed  up  this  process. 

Graphics  should  be  sketched  freehand  or  photocopied.  Placement  and 
general  content  of  learner-system  interactions  and  test  items  should  be  noted 
without  going  into  detail.  Record  your  text  and  graphics  sources  for  future 
reference. 

Include  all  opening,  menu,  closing,  and  exit  screens,  one  per  sheet  of 
paper.  You  may  find  it  useful  to  indicate  content  that  will  appear  in  another 
medium  (e.g.,  course  guide,  reference  card,  videotape)  by  inserting  a  colored 
sheet  at  the  appropriate  point.  The  form  shown  in  Figure  4-2  appeared  on 
blue  sheets  in  the  "About  AISIM"  Preliminary  Design  Report. 
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Page  # 


Module  # _  Previous  Page/Screen  ft 

Module  Name _  Next  Page/Screen  # _ 


Special  instructions,  questions 


Figure  4-2.  Blue  Sheet  for  "About  AISIM"  Course  Guide  Reference. 
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4.4  Step  4:  Draft  Course  Guide 

A  natural  by-product  of  expanding  the  detailed  outlines  to  a 
Preliminary  Design  Report  is  the  first  draft  of  the  course  guide  that  will 
accompany  the  courseware.  Whether  the  guide  is  two  pages  long  or  200, 
learners  should  have  some  way  of  finding  out  what  they  are  getting  into 
without  having  to  load  a  mag  tape  or  insert  a  diskette.  The  "About  AISIM" 
Course  Guide's  table  of  contents  are  shown  in  Figure  4-3.  Note  that  "About 
AISIM"  is  a  stand-alone,  self-paced  instructional  system. 

The  instructor's  manual  is  an  essential  component  for  the  success  of  CAI 
systems  that  support  an  instructor-led  course.  Section  6-16,  AFP  50-58, 

Volume  IV,  lists  information  recommended  for  inclusion  in  the  instructor's 
manual.  Consult  with  your  project's  assigned  instructor  and/or  SME  to 
determine  other  information  to  include. 


4.5  Step  5:  Draft  Screen  Design  Standards 

Another  by-product  of  Phase  II/Step  1  is  the  first  draft  of  the  screen 
design  standards.  Heck  (1986)  lists  direction  for  authors,  quality,  consistency, 
and  ease  of  maintenance  as  the  four  primary  purposes  of  CAI  development 
standards.  Standards  will  also  facilitate  team  communications  in  Phases  III 
and  IV.  These  standards  should  include  conventions  governing  graphics  as 
well  as  text.  Graphics  standards  are  addressed  in  Section  5.1.2  of  this 
handbook. 

A  copy  of  the  Design  Guidelines  for  User-Svstem  Interface  Software. 
ESD-TR-84-190,  is  available  upon  request  from  the  Computer  Resource 
Management  Technology  Program  Office,  Electronic  Systems  Division,  Hanscom 
Air  Force  Base,  MA.  Although  the  Design  Guidelines  were  compiled  for 
designers  of  user-system  interface  software  in  defense  information  systems, 
they  are  an  excellent  resource  for  anyone  responsible  for  screen  design. 

Screen  design  standards  can  be  developed  in  a  number  of  ways.  One 
way  is  to  tailor  existing  standards  to  meet  the  needs  of  your  project.  Another 
approach  is  to  develop  your  own  standards.  This  usually  means  allowing 
standards  to  evolve  over  the  course  of  Phases  II  and  III,  making  certain  that 
you  document  them  as  they  evolve. 

While  tailoring  existing  standards  is  certainly  easier,  the  standards  you 
begin  with  may  have  been  written  under  constraints  that  your  design  skills, 
authoring  system,  or  delivery  system  could  have  overcome.  In  other  words, 
your  creativity  and  the  capabilities  of  your  technology  may  be  short-circuited 
by  starting  with  existing  standards. 

If  you  adopt  existing  standards,  find  out  what  authoring  system  and 
computer  they  were  developed  for.  It  would  also  be  helpful  to  view 
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courseware  developed  under  those  standards  to  see  exactly  what  they  mean. 

If  you  decide  to  develop  your  own  standards,  research  the  topic  first.  Books, 
journals,  conferences,  authoring-system  users  groups,  other  agencies  or 
companies,  demonstrations,  and  commercial  products  are  good  sources  of  the 
latest  experimental  results,  practical  guidelines,  lessons  learned,  in-house 
standards,  bug-free  examples,  and  free  advice.  See  the  appendixes  for  more 
information. 

Whether  you  rely  on  existing  standards  or  develop  your  own,  they 
should  address  topics  such  as  language,  grammar,  capitalization,  abbreviation, 
and  graphics  conventions;  basic  screen  types  and  standard  screens;  and  screen 
identification  and  transfer  data. 

Sample  screen  design  standards  are  presented  in  Appendix  F  of  this 
handbook.  This  set  of  standards  was  developed  for  "About  AISIM,"  a 
sixteen-hour  tutorial  which  presently  runs  on  an  IBM-PC.  Members  of  the 
development  team  sought  information  from  a  variety  of  the  sources  listed 
above,  then  debated  and  agreed  upon  standards  as  screen  design  issues  arose. 
The  team’s  technical  editor  was  in  charge  of  documenting,  updating,  and 
distributing  each  iteration  of  the  standards  as  they  evolved. 


4.6  Step  6:  Experiment  with  Authoring  System 

Although  you  are  far  from  being  ready  to  transfer  storyboards  to  the 
authoring  sytem,  experimentation  with  the  authoring  system  at  this  time 
could  prove  very  helpful.  Experimentation  is  especially  valuable  if  (1)  you  are 
using  an  unfamiliar  authoring  system  or  (2)  your  proposed  courseware  design 
is  more  complex  than  your  earlier  products. 

For  example,  Lt  Swift's  previous  products  were  fairly  simple  drill-and- 
practice  exercises.  Now,  however,  she  has  been  tasked  to  produce  a  tutorial, 
including  detailed  graphics  and  several  levels  of  remediation.  While  she  is 
comfortable  with  most  of  the  authoring  system's  features,  she  is  certain  that 
experimenting  with  graphics,  whether  character  or  bit-map,  and  more 
complicated  branching  for  remediation  will  prevent  snafus  later. 

As  discussed  in  Phase  I,  the  question  of  transportability  from  color  to 
monochrome  or  to  another  computer  altogether  (e.g.,  from  an  IBM-PC  to  a 
Zenith)  may  be  an  issue  for  your  project.  If  so,  you  should  also  run  computer 
system  checks  with  the  authoring  system  at  this  time. 

Text  that  blinks  in  color  may  produce  blanks  in  monochrome.  Text  that 
is  blue  on  a  color  monitor  may  appear  as  an  underline  on  a  monochrome 
monitor.  These  differences  are  unimportant  if  you  will  be  running  the 
courseware  exclusively  on  the  color  machines  at  your  facility.  However,  if  you 
plan  to  make  the  courseware  available  to  Government  or  contractor  personnel 
at  other  facilities,  it  would  be  wise  to  exclude  such  differences  from  your 
design. 


a  n 


Section  4/Phase  II 


Again,  design  constraints  vary  among  authoring  systems  and  among 
computer  systems.  Your  best  defense  against  future  problems  is  to 
experiment  with  the  authoring  system's  capabilities  on  the  target  computer(s) 
during  Phase  II. 


4.7  Step  7:  Review  Each  Unit 

This  step  introduces  the  issue  of  the  courseware  review  cycle.  Good 
quality  is  built  into  a  CAI  system  from  ISD  Step  1  onward,  not  simply  assured 
in  Steps  4  and  5.  Regular  reviews  of  each  unit  and  then  of  the  course  as  a 
whole  are  an  important  tool  for  building  in  good  quality.  The  ESD  prototype 
methodology  includes  review/revision  steps  in  each  of  its  five  phases  to 
emphasize  the  necessity  of  this  activity.  Phases  I  through  IV  address 
formative  evaluation,  while  Phase  V  addresses  summative  evaluation. 

Kearsley  (1983)  defines  formative  evaluation  as  "data  collected  to  make 
decisions  about  revisions  and  improvements,"  (p.  107).  Summative  evaluation 
is  "data  collected  in  order  to  make  decisions  about  the  overall  value  of  CBT 
[computer-based  training],"  (p.  108)  or  any  other  instructional  system. 

The  review/revision  cycle  gives  the  team  opportunities  to  review  the 
material  as  a  whole  rather  than  in  bits  and  pieces.  It  also  requires  the  team  to 
set  and  meet  due  dates,  discuss  and  resolve  problems,  and  make  tangible 
progress  toward  the  next  milestone. 

Section  6-19,  AFP  50-58,  Volume  IV,  provides  information  on  how  to 
conduct  an  internal  review  of  the  initial  draft.  Note  the  emphasis  on  having 
the  reviewer  identify: 

•  Strengths  as  well  as  weaknesses 

•  Specific  suggestions  for  how  to  improve  identified  weaknesses. 


Quality  factors  cited  in  DOD-STD-2167  include: 


•  Reliability 

•  Correctness 

•  Reusability 

•  Integrity 


•  Portability  •  Efficiency 

•  Maintainability  •  Interoperability 

•  Flexibility  •  Testability 

•  Usability 


Not  all  of  the  "-ilities"  are  relevant  to  CAI,  but  they  do  bear  consideration  in 
your  review  process. 
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4.8  Step  8:  Review/Revise  Course 

This  step  appears  again  in  Phases  III  and  IV.  Its  purpose  is  to 
emphasize  integration  of  all  parts  of  the  system  your  team  is  developing: 
screen  contents,  both  text  and  graphics,  and  ancillary  materials,  both  the 
learner's  and  instructor's  guides.  Your  guideposts  throughout  this  process  are 
the  instructional  objectives  you  devised  in  ISD  Step  3. 

The  output  of  Phase  II  is  the  Preliminary  Design  Report.  The  PDR  is  a 
rough  sketch  of  the  proposed  CAI  system  created  for  internal  review  and 
revision.  This  set  of  rough  storyboards  and  ancillary  materials  determines  the 
general  shape  the  CAI  system  will  take  in  Phase  III.  Its  completion  gets  you 
over  the  first  major  design  hurdle  and  prepares  you  for  Phase  III,  Detailed 
Design. 


Because  its  primary  purpose  is  to  facilitate  internal  review  and  revision, 
the  PDR  is  not  listed  as  a  formal  milestone  in  the  prototype  methodology. 
However,  you  may  want  your  approving  agency  to  review  it  informally  to 
make  sure  everyone  is  still  on  the  same  wavelength. 
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Phase  III:  Detailed  Design 


To  complete  Phase  II,  Preliminary  Design,  your  development  team 
sketched  out  a  set  of  rough  storyboards  for  internal  review.  You  also  began 
drafting  two  documents:  (1)  the  course  guide  and  any  other  ancillary  materials 
or  media,  and  (2)  the  screen  design  standards  that  the  team  will  follow  in 
Phase  III.  You  may  have  also  chosen  and  experimented  with  an  authoring 
system.  Consequently,  the  four  products  of  Phase  II  were: 

1)  Preliminary  Design  Report  (PDR),  which  is  a  set  of  rough  storyboards 

2)  Draft  course  guide,  instructor's  manual,  and  other  ancillary  material 

3)  Draft  screen  design  standards 

4)  Documented  results  of  the  authoring  system  check 

Phase  III,  the  detailed  design  process,  is  the  apex  of  your  CAI  develop¬ 
ment  effort.  Figure  5-1  shows  the  nine  steps  of  this  phase. 


5.1  Step  1:  Expand  PDR  to  Draft  Detailed  Design  Report 

You  developed  the  Preliminary  Design  Report  (PDR)  for  internal  review 
purposes,  although  you  may  have  had  outside  readers  review  it  as  well.  Once 
the  "visual  outline"  of  the  logic  flow  and  basic  content  are  judged  satisfactory, 
your  team  is  ready  to  add  detailed  content  and  graphics.  The  result  is  the 
Draft  Detailed  Design  Report  (DDDR).  Step  1  is  comprised  of  five  smaller 
activities,  which  are  described  below. 

5.1.1  Step  1.1:  Review/Revise  Instructional  Flow  and  Pace 

Although  you  reviewed  the  sequencing  and  grouping  of  the  course 
objectives  several  times  prior  to  and  during  Phases  I  and  II,  you  must  check 
the  instructional  flow  and  pace  again  before  the  course  solidifies  further. 

Section  5-17e  of  AFP  50-58,  Volume  IV,  offers  high-level  guidance  aimed  at 
"compromises  and  changes  in  sequencing"  during  final  media  selection. 

Review  that  section  again  and  ask  yourself  questions  such  as: 

Ql:  Is  the  flow  logical  and  consistent? 

Q2:  Can  the  learner  predict  the  flow  from  one  unit  to  the  next, 

or  does  he/she  have  to  learn  a  new  set  of  procedures  for  each  unit  ? 
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Figure  5-1.  Phase  III:  Detailed  Design. 
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Q3:  Is  the  learner  required  to  complete  an  inordinate  number  of 
screens  between  interactions  or  test  items? 

These  questions  do  not  begin  to  scratch  the  surface  of  the  topic  of  instructional 
flow  and  pace.  Almost  any  text  on  educational  psychology  or  instructional 
design  would  provide  further  assistance.  Concepts  from  film-making  and 
video  production,  especially  animation,  can  easily  be  adapted  for  CAI  flow  and 
pacing  guidelines. 

5.1.2  Step  1.2:  Review/Revise  Screen  Designs 

Brink  (1986)  wrote  that  "Thoughtful  consideration  of  screen  format  and 
design  is  critical  for  successful  CBT— perhaps  equal  in  importance  to  actual 
course  content.  Poor  screen  design  by  itself  can  cause  product  failure,"  (p.  23). 
He  is  only  one  of  hundreds  of  interface  designers  who  continue  to  stress  the 
importance  of  screen  design.  And  the  greater  the  size  and  complexity  of  your 
CAI  system,  the  more  important  it  is  to  document  screen  design  decisions  in  a 
set  of  standards,  as  discussed  in  Section  4.5  of  this  handbook. 

Whether  you  chose  to  develop  your  own  set  of  standards  or  adopt  an 
existing  set  for  Step  5  of  Phase  II,  you  should  review  and  revise  them  at  this 
time.  Much  of  the  input  for  this  review  and  revision  can  probably  be  gleaned 
from  comments  made  about  the  PDR  at  the  conclusion  of  Phase  II. 

As  the  CAI  task  manager,  you  are  responsible  for  keeping  abreast  of  all 
facets  of  the  project.  Development  team  communication  is  greatly  enhanced, 
however,  by  continuing  to  review,  revise,  and  distribute  the  screen  design 
standards  you  began  drafting  earlier.  The  project's  technical  editor  and/or 
graphics  designer  could  be  assigned  the  task  of  maintaining  the  standards, 
notifying  all  team  members  of  changes  and  answering  questions  that  may 
arise. 


By  now  you  have  a  fairly  clear  idea  of  what  the  menu  and  branching 
logic  is,  how  long  each  branch  of  each  unit  will  be,  and  how  long  the  course  as 
a  whole  will  be.  That  information  gives  you  an  indication  of  how  many  land¬ 
marks  and  signposts  the  learner  will  be  seeking.  The  more  complex  your 
menu  and  branching  logic,  the  more  guidance  you  will  want  to  give  the  learner 
on  each  screen. 

ESD-TR-84-190,  Design  Guidelines  for  User-Svstem  Interface  Software, 
addresses  user  guidance  in  Section  4.  Here,  user  guidance  encompasses  "error 
messages,  alarms,  prompts,  and  labels,  as  well  as.. .more  formal  instructional 
material  provided  to  help  guide  a  user's  interaction  with  a  computer,"  (p.  261 ). 
Section  2  of  the  Guidelines.  "Data  Display,"  offers  valuable  rules  of  thumb  on 
such  topics  as  text,  tables,  and  graphics  display;  density;  and  framing. 

If  you  are  using  an  authoring  system,  many  screen  features  may  be 
dictated  to  you  (e.g.,  placement  of  the  "back"  and  "exit"  prompts).  However. 
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the  additional  landmarks,  signposts,  and  other  evidence  of  learner-friendliness 
that  you  build  into  each  screen  can  make  a  significant  difference  in  how 
positively  learners  react  to  your  CAI  product. 

Examples  include  placing  a  locational  banner  in  the  upper  right  comer 
of  each  screen  and  hardcopy  page  (note  the  top  of  this  page).  Also,  learners 
tend  to  be  especially  uncomfortable  with  tests.  In  the  introduction  to  a  test 
section,  tell  learners  how  many  questions  they  are  going  to  be  asked.  Then 
number  the  questions  as  you  present  them. 

Learner-friendliness  is  often  a  CAI  translation  of  courtesies  you  would 
automatically  extend  in  the  classroom.  Imagine  your  students'  reaction  if  you 
silently  distributed  a  reading  assignment  or  administered  an  exam  one 
unnumbered  page  at  a  time.  The  fact  that  CAI  learners  will  take  out  their 
frustrations  on  the  computer  rather  than  on  your  person  should  not  keep  you 
from  building  in  learner-friendliness. 

5.1.3  Step  1.3:  Add  Text  and  Graphics 

The  next  step  in  expanding  the  PDR  into  the  Draft  Detailed  Design  Report 
(DDDR)  is  to  add  text  and  graphics.  Team  members  may  have  been  noting  text 
sources  and  sketching  rough  graphics  as  they  prepared  the  PDR,  but  those 
activities  are  now  the  primary  focus.  At  least  two  options  are  available. 

Option  1  calls  for  cutting  and  pasting  unedited  text  from  existing 
materials.  These  materials  could  range  from  copies  of  the  user's  guide  to  a 
college  textbook  to  notes  from  your  interviews  with  subject-matter  experts. 

You  would,  of  course,  rewrite,  edit,  and  supplement  these  materials  before 
submitting  the  Draft  Detailed  Design  Report  for  Government  approval.  Use 
copyrighted  material  cautiously,  even  in  a  draft  that  will  be  rewritten  and 
edited  extensively.  If  you  choose  Option  1, 

•  Reference  your  sources,  especially  copyrighted  ones 

•  Identify  material  that  is  DOD  property 

•  If  you  decide  to  use  copyrighted  material,  incorporate  the  ideas 

in  your  own  wording  to  avoid  plagiarism 

Option  2  calls  for  assembling  the  same  materials  that  you  would  have 
gathered  for  Option  1.  The  main  difference  is  that  you  would  rewrite  and  edit 
the  text  before  transferring  it  to  storyboards  for  the  PDDR.  The  result  would 
not  be  polished  to  the  point  of  publication,  but  it  would  be  more  of  a  book 
than  a  set  of  storyboards. 


5-4 


Section  5/Phase  III 


To  summarize  the  two  options: 


Option  1 

1)  Assemble  materials 

2)  Review  materials 

3)  Discuss  and  resolve  problems 

4)  Revise  flow  and  content 

5)  Rewrite  materials 

6)  Transfer  to  storyboard  format 


Option  2 

1)  Assemble  materials 

2)  Rewrite  materials 

3)  SME  reviews  and  revises 

4)  Review/revise  flow 

5)  Transfer  to  storyboard  format 


Either  option  has  benefits  and  drawbacks.  The  main  advantage  of 
Option  1  is  that  everyone  has  a  clearer  picture  of  how  the  course  will  look  and 
flow  early  in  the  detailed  design  process.  A  review  of  Option  l's  output  will 
prevent  you  from  rewriting  text  that  may  soon  be  deleted.  A  disadvantage  of 
Option  1  is  that  it  if  Steps  3  and  4  are  group  processes,  this  option  can  become 
very  time-consuming. 

The  main  advantage  of  Option  2  is  that  by  creating  the  definitive 
"course  document,"  everyone  has  a  common  departure  point  and  reference  for 
the  remainder  of  the  project.  This  course  document  would  be  convenient  for 
the  SME  to  review  and  revise,  as  it  would  be  a  cohesive  whole  rather  than  a 
conglomerate  of  widely  different  sources.  A  disadvantage  of  Option  2  is  that 
some  of  the  effort  spent  creating  a  course  document  is  negated  in  the  process 
of  creating  interactive,  individualized,  interesting  courseware.  What  makes  a 
cohesive  whole  on  paper  does  not  translate  into  CAI,  unless  the  CAI  product  is 
to  be  an  electronic  page-turner. 

Perhaps  the  best  path  lies  between  the  two  options.  After  your 
developers  assemble  their  sources,  frequently  touch  bases  with  each 
individual.  "Management  by  wandering  around"  will  help  keep  everyone  on 
target.  When  global  issues  arise,  either  call  a  brief  meeting  or  save  the  issues 
for  your  next  weekly  team  meeting,  depending  on  the  nature  of  the  problem. 

Graphics  for  either  option  should  be  limited  to  freehand  sketches  and 
illustrations  photocopied  from  either  DOD  property  or  properly  referenced 
copyrighted  sources.  Label  figures,  tables,  and  other  graphics  by  title  and 
intended  location. 

Have  your  graphic  artist  and  your  computer/authoring-system 
specialist  begin  experimenting  with  graphics  that  appear  more  than  once  in 
the  courseware.  This  will  produce  three  results: 

1 )  Speed  up  the  graphics  standardization  process 

2)  Give  the  team  a  better  idea  of  the  delivery  system's 

graphics  capabilities 

3)  Start  your  on-line  graphics  library  for  Phase  IV 
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5.1.4  Step  1.4:  Add  Interactions 

Interaction  is  the  heart  of  computer-assisted  instruction.  The  computer 
program's  abilities  to  judge  learner  answers  and  respond  appropriately  are 
the  medium's  main  advantages.  Therefore,  lively  interaction  is  the  hallmark 
of  a  good  CAI  system. 

Technically,  "interaction"  refers  to  any  communication  between  user 
and  computer.  In  this  handbook,  however,  the  term  will  refer  to  communi¬ 
cations  within  branches  that  are  not  intended  to  measure  mastery  of 
objectives.  These  interactions  may  reinforce  a  point  just  made  or  provide 
information  for  a  problem-solving  exercise,  but  they  are  not  test  items. 

AFP  50-58,  Volume  VI,  is  a  good  starting  place  for  a  discussion  of 
interaction.  Note  that  Volume  VI  is  not  limited  to  CAI.  See  the  list  of 
recommended  readings  too,  as  much  has  been  written  on  this  topic. 

As  you  roughed  out  the  PDR  in  Phase  II,  you  noted  (1)  placement  of 
interactions  and  (2)  the  contents  of  those  interactions  within  each  branch.  One 
rule  of  thumb  suggests  that  the  learner  interact  with  the  system  at  least  once 
every  three  full  screens  or  once  every  six  half-screens.  More  interactions  are 
usually  better  than  fewer,  but  your  topic  may  dictate  fewer,  or  quality  may 
not  be  able  to  match  quantity.  In  either  of  those  cases,  you  will  have  devise 
your  own  rule  of  thumb.  To  complete  this  step  of  Phase  III,  write  out  fully 
the  interactive  questions,  answers,  and  system  responses  that  you  noted  in 
Phase  II. 

5.1.5  Step  1.5:  Add  Test  Items 

Section  4-4  of  AFM  50-2  addresses  test  development.  Chapters  4  and  5, 
AFP  50-58,  Volume  III,  present  more  detailed  discussions  of  criterion- 
referenced  test  construction  and  use.  You  probably  reviewed  these  before 
writing  the  test  items  for  ISD  Step  3.3  and  reviewing  your  items  for  Step  4  of 
Phase  II. 

Tests  serve  at  least  two  purposes.  First,  they  enable  the  learner  and  the 
instructor  to  assess  self-performance.  The  learner  is  given  feedback  on  his  or 
her  degree  of  mastery,  while  the  instructor  gains  feedback  on  how  well  he  or 
she  communicated  with  the  learner. 

Second,  from  an  ISD  viewpoint,  tests  enable  the  instructional  designer  to 
assess  system  performance.  Test  items  are  the  designer's  single  best  source  of 
information  about  how  well  an  instructional  system  functions. 

At  one  extreme,  test  items  are  excluded  from  instruction  for  fear  of 
intimidating  or  otherwise  alienating  the  learner.  Learners,  instructors  (or 
supervisors),  and  designers  are  all  denied  valuable  information  by  this 
approach. 
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At  the  other  extreme,  learners  are  simply  throughput  to  monitor  system 
performance.  Adherents  to  this  approach  may  improve  instructional  system 
performance  at  the  expense  of  learner-friendliness.  Ideally,  you  will  be  able 
to  find  a  middle  ground  between  the  two  extremes.  It  may  help  to  recall  that 
learners  are  typically  more  alienated  by  the  way  test  results  are  communi¬ 
cated  rather  than  by  the  fact  that  they  are  communicated. 


5.2  Step  2:  Review/Revise  Each  Unit 
See  Step  7  of  Phase  II. 


5.3  Step  3:  Review/Revise  Course 
See  Step  8  of  Phase  II. 


5.4  Milestone  2:  Government  Approval  of  DDDR 

The  Government's  comments  and  recommended  revisions  are 
responded  to  as  outlined  in  Section  3.9  of  this  handbook.  Before  incorporating 
any  changes,  however,  conduct  Step  4. 


5.5  Step  4:  Conduct  Individual  Tryouts 

Once  the  Government  has  approved  the  Draft  Detailed  Design  Report, 
have  at  least  two  or  three  above-average  learners  from  the  target  population 
work  through  the  DDDR's  paper-based  storyboards  and  ancillary  materials. 
Granted,  working  through  a  paper-based  version  of  a  CAI  system  does  not 
simulate  the  on-line  system  very  closely.  But  learners'  substantive  comments 
and  recommended  revisions  are  easier  to  incorporate  now  rather  than  after 
the  storyboards  have  been  transferred  to  the  authoring  system.  Individual 
tryouts  are  conducted  with  the  on-line  courseware  in  Step  8  of  Phase  IV  or 
sooner,  depending  on  learner  availability. 

In  keeping  with  ISD's  iterative  nature,  Step  4  gives  you  the  opportunity 
to  gather  two  types  of  data:  (1)  student  feedback  on  contents  and  flow  of  the 
course  thus  far  and  (2)  initial  system  validation.  Section  5-4b,  AFM  50-2, 
states: 


In  developing  an  instructional  system,  the  proof  of  quality  can 
only  be  ascertained  through  a  measurement  of  results  in 
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comparison  with  the  specific  criterion  objectives.  Each  step  in 
instructional  system  development  can  be  validated  by  checking 
student  performance  against  the  performance  criteria.  This  is 
referred  to  as  system  validation.  It  should  not  be  inferred, 
however,  that  the  complete  instructional  system  is  developed 
and  then  tested  all  at  once;  rather,  portions  of  it  may  be  tested 
as  they  are  produced,  (p.  5-19). 

Put  another  way,  good  quality  is  built  in  by  frequently  reviewing  the  material 
and,  now  that  the  course  is  taking  shape,  by  testing  it  out  with  individuals. 
Section  5-4b(l)  addresses  individual  student  sampling  and  conducting  the 
individual  tryout.  Sections  6-20  through  -22,  AFP  50-58,  Volume  IV  give 
more  detailed  guidance  on  this  topic.  Stress  to  the  learners  participating  in 
your  individual  tryouts  that  the  courseware  is  being  evaluated,  not  the 
learner. 


5.6  Step  5:  Refine  Draft  to  Final  Detailed  Design  Report 

The  Final  Detailed  Design  Report  (FDDR)  is  a  set  of  hardcopy  storyboards 
submitted  on  screen  templates  from  your  authoring  system.  Appendix  E 
contains  the  screen  templates  used  for  "About  AISIM."  This  set  was  intended 
to  meet  the  informational  requirements  of  most  authoring  systems. 

The  purpose  of  the  FDDR  is  to  incorporate  and  integrate  valid  comments, 
suggestions,  and  recommended  revisions  provided  by  the  Government, 
individual-tryout  participants,  instructors,  and  the  development  team.  Section 

5- 4  of  APM  50-2  briefly  describes  use  of  individual  tryout  results.  Sections 

6- 23  through  -28,  AFP  50-58,  Volume  IV,  provide  valuable  guidelines  for 
analyzing  tryout  data  and  making  needed  revisions. 

This  step  also  calls  for  polishing  the  text  and  graphics  to  their  final 
paper-based  version.  Here,  "polishing"  means  having  the  instructional 
developers  refine  each  branch,  paying  particular  attention  to  transitions, 
interactions,  and  test  items.  Close  attention  must  be  paid  to  having  the  course 
guide  and  any  other  ancillary  materials  accurately  and  consistently  reflect  any 
changes  made  to  the  courseware. 

The  technical  editor  edits  each  storyboard  and  accompanying 
course-guide  page  as  the  developers  complete  their  work.  The  graphics 
designer  produces  final  illustrations  for  the  courseware  and  its  ancillary 
materials.  Later,  masters  of  these  graphics  are  filed  by  unit,  then  photocopied 
and  pasted  to  their  respective  storyboards  and  ancillary  pages  during 
production  of  the  Final  Detailed  Design  Report. 
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5.7  Step  6:  Revise  Screen  Design  Standards 

Revision  of  the  screen  design  standards  is  critical  at  this  point  because 
the  entire  development  team  will  be  relying  on  them  heavily  over  the  rest  of 
this  phase  as  well  as  in  Phase  IV.  Include  any  global  changes  that  were  made 
in  Step  5  and  append  a  set  of  the  graphics  that  appear  more  than  once.  See 
Appendix  F  of  this  handbook  for  an  example. 


5.8  Step  7:  Review/Revise  Each  Unit 

Development  team  members  review  each  unit  on  their  own,  then  meet 
to  discuss  any  final  changes.  Reviewing  and  revising  the  units  in  sequence 
promotes  consistency  across  the  course. 


5.9  Step  8:  Review/Revise  Course 

If  you  have  access  to  a  reviewer  who  has  not  been  involved  in  the 
current  development  process,  have  him  or  her  review  the  courseware  and  its 
ancillary  materials.  This  reviewer  should  note  inconsistencies,  weak  or 
nonexistent  transitions,  unnecessary  redundancy,  and  ambiguity  or  other 
wording  problems.  Incorporation  of  this  reviewer's  comments  should  be 
limited  to  fine-tuning. 


5.10  Step  9:  Word-Process  Text 

The  word-processing  capabilities  of  most  authoring  systems  are  more 
cumbersome  than  those  of  programs  whose  main  purpose  is  word-processing. 
If  you  have  a  lot  of  text  to  input,  it  is  more  efficient  to  enter  it  into  word¬ 
processing  files  that  can  be  transferred  in  Step  1  of  Phase  IV.  Make  certain 
that  the  word-processing  program  is  compatible  with  your  authoring  system 
before  inputting  the  Final  Detailed  Design  Report  storyboards.  Proofreading 
this  input  is  a  monumental  task,  even  with  an  on-line  spelling-check  feature. 

Your  computer  specialist  has  been  experimenting  with  and  inputting 
graphics  into  the  authoring  system's  graphics  library  since  Step  1 .3  of  Phase 
Ill.  He  or  she  should  now  revise  them  to  be  consistent  with  the  master 
graphics  developed  in  Step  5  of  this  phase. 


5.11  Milestone  3:  Government  Approval  of  Final  Detailed  Design 
Report 

Once  you  reach  Milestone  3,  the  courseware  storyboards  are  "frozen"  by 
Government  approval.  Minor  spatial  and  color  adjustments  may  need  to  be 
made  in  Phase  IV,  but  any  other  changes  should  first  meet  with  Government 
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approval.  The  review  procedure  established  in  Step  3.9  of  Phase  I  should  be 
followed  here  to  ensure  that  all  parties  are  aware  of  and  approve  of  what  will 
later  appear  on  the  computer  screen  and  in  the  ancillary  materials. 
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Phase  IV:  Transfer  and  Validation 


To  complete  Phase  III,  Detailed  Design,  you  expanded  the  Preliminary 
Design  Report  to  the  Draft  and  Final  Detailed  Design  Reports.  You  also  revised 
the  screen  design  standards  and  the  course  guide,  as  well  as  any  other 
ancillary  materials.  You  may  have  also  begun  transferring  storyboard  text  to 
word -processing  files  that  you  will  transfer  to  the  authoring  system  in  this 
phase.  The  products  of  Phase  III  included  the  following: 

1)  Draft  Detailed  Design  Report  (DDDR) 

2)  Final  Detailed  Design  Report  (FDDR) 

3)  Revised  screen  design  standards 

4)  Revised  course  materials,  including  the  learner's 

and  instructor's  guides 

5)  Word-processing  files 

Your  CAI  development  effort  will  begin  winding  down  in  Phase  IV, 
especially  if  you  are  already  familiar  with  your  authoring  system  (or 
authoring  or  programming  language).  Figure  6-1  shows  the  six  steps  of  this 
phase. 


6.1  Step  1:  Transfer  Storyboards  to  Authoring  System 

Execution  of  this  step  varies,  depending  on  your  authoring  system.  As 
noted  in  Sections  4.6  and  5.1 ,  your  best  defense  against  future  problems  was 
to  experiment  with  the  authoring  system  on  the  target  computer(s)  during 
Phases  II  and  III.  Assuming  you  experimented  with  the  system  sufficiently 
before  you  began  designing  the  courseware  in  earnest,  transferring  the 
storyboards  you  produced  for  the  Final  Detailed  Design  Report  will  be  fairly 
straightforward.  Transferring  a  large  number  of  screens  and  tracking  them 
carefully  will  probably  comprise  most  of  the  challenge  in  this  phase. 


If  you  chose  to  enter  storyboard  text  into  word-processing  files  in 
preparing  the  Final  Detailed  Design  Report,  you  are  a  step  ahead  for  this  phase. 
If  you  decided  to  enter  the  storyboard  text  directly  into  the  authoring  system, 
you  may  have  to  contend  with  an  inefficient  word-processing  program  within 
the  authoring  system.  In  either  case,  this  step  is  tedious  and  requires  close 
attention  to  detail  in  order  to  minimize  courseware  bugs. 
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Figure  6-1.  Phase  IV:  Transfer  and  Validation. 


6-2 


Section  6/Phuse  IV 


The  graphics  library  you  began  building  in  Step  1  of  Phase  III  should 
prove  useful  now,  as  you  will  probably  be  able  to  insert  and  recycle  many 
graphics.  You  may  need  to  make  minor  fine-tuning  adjustments  to  the  on-line 
text  and  graphics  to  correct  spacing  or  other  unforeseen  problems. 

No  changes  in  course  content  should  be  made  after  Government 
approval  of  the  Final  Detailed  Design  Report,  Milestone  4  in  Phase  III.  If 
changes  other  than  spatial  or  color  adjustments  are  deemed  necessary,  those 
changes  should  first  be  approved  by  the  office  that  approved  the  FDDR.  After 
the  proposed  changes  have  been  approved,  all  changes  should  be  documented 
on  a  copy  of  the  FDDR  for  future  reference.  Because  this  introduces  so  much 
more  opportunity  for  inconsistency  and  other  courseware  bugs,  changes  to  the 
FDDR  should  be  avoided. 


6.2  Step  2:  Verify  Courseware 

The  purpose  of  this  step  is  basic  quality  assurance  (QA),  to  catch  and 
correct  any  typographical  errors,  missing  elements,  or  improper  branching 
before  the  learner  discovers  them.  Since  this  prototype  methodology 
provides  opportunities  for  building  in  high  quality  all  through  the 
development  process.  Step  2  should  simply  be  a  final  verification  of  the 
on-line  courseware  against  the  storyboards  set  forth  in  the  Final  Detailed 
Design  Report. 

As  discussed  in  DOD-STD-2167,  software  quality  evaluation  is  an 
ongoing  process.  The  contractor  is  required  to  maintain  records  of  and  report 
each  quality  evaluation  that  is  performed.  The  contractor  must  also  be  able  to 
provide  evidence  indicating  that  the  products  meet  all  contractual 
requirements.  Most  importantly,  these  activities  "shall  be  performed  by 
individuals  who  have  sufficient  responsibility,  authority,  resources,  and 
independence  to  accomplish  objective  evaluation  of  the  products  and  activities 
being  reviewed.  The  degree  of  independence  varies  with  such  factors  as 
project  complexity  and  criticality,"  (Section  5.8.3). 

Your  product  may  not  warrant  a  high  degree  of  independence  in  its 
quality  evaluators.  But  it  is  important  to  have  at  least  one  objective  person,  a 
quality  assurance  tester,  review  the  courseware  at  this  point.  The  QA  tester 
should  (1)  be  recruited  from  outside  your  immediate  group  or  office;  (2)  have 
a  sharp  eye  for  detail,  including  spelling;  and  (3)  be  painstakingly 
conscientious.  Most  competent  technical  proofreaders  and  editors  meet  the 
second  and  third  requirements. 

The  QA  tester  checks  each  unit  as  the  task  manager  completes  his  or  her 
review  of  each.  Ideally,  at  least  two  testers  would  work  through  each  unit. 
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6.3  Step  3:  Review  QA  Comments 

The  QA  tester  should  have  flagged  any  discrepancies  between  the 
directions,  text,  and  graphics  set  forth  in  the  storyboards  and  those  that 
appear  in  the  on-line  courseware.  Particularly  important  are  those  that  create 
problems  for  the  learner.  Significant  problems  arise  from  incorrect  branching 
directions  and  missing  information,  so  these  must  be  given  top  priority  in  Step 
4  of  this  phase. 

The  bulk  of  project  resources  will  have  been  expended  prior  to  Phase 
IV.  Consequently,  you,  as  the  task  manager,  have  to  weigh  the  must-change 
problems  (such  as  incorrect  branching  or  missing  screens)  against  the 
nice-to-change  problems  noted  by  the  QA  tester. 


6.4  Step  4:  Debug  Courseware 

Correcting  problems,  or  "debugging  the  program,"  is  a  normal  part  of 
every  software  development  task.  CAI  is  no  exception.  Corrections  will 
probably  also  need  to  be  made  in  the  course  guide,  the  instructor's  manual, 
and  any  other  ancillary  materials  so  that  information  is  consistent  across 
media. 


To  begin  this  step,  you  will  have  determined  which  changes  the  project 
resources  can  support.  One  of  the  highest  drivers  in  minimizing  changes  at 
this  late  date  will  probably  be  time.  Given  how  long  it  takes  to  develop  CAI, 
your  intended  user  will  not  appreciate  your  lengthening  the  development 
schedule  to  make  unnecessary  tweaks. 

Once  you  have  identified  which  of  the  problems  will  be  fixed,  your 
authoring  system  programmer  can  go  ahead  and  make  those  changes.  To  help 
maintain  consistency,  all  changes  should  be  documented  on  a  copy  of  the  Final 
Detailed  Design  Report  storyboards.  This  record  of  changes  is  critical  for  later 
verifying  that  the  problems  have  been  corrected. 


6.5  Step  5:  Update  Screen  Design  Standards 

This  step  is  more  of  an  investment  in  your  future  CAI  projects  than  in 
the  one  you  are  completing.  It  will  be  helpful  to  update  the  screen  design 
standards  at  this  point  to  reflect  changes  that  were  made  in  either  (1) 
transferring  the  storyboards  to  the  authoring  system  or  (2)  responding  to  the 
QA  tester’s  comments. 

No  doubt  you  will  tailor  the  screen  design  standards  to  meet  the  needs 
of  your  next  project.  But  starting  with  a  set  that  accurately  reflects  the  final 
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product  of  this  project  will  help  speed  up  the  next  project's  design  process. 
This  step  can  be  completed  by  the  technical  editor  while  the  authoring  system 
programmer  is  debugging  the  courseware. 


6.6  Step  6:  Validate  Courseware 

Validating  any  instructional  program  means  answering  the  question, 
"Does  this  instructional  program  enable  learners  to  meet  its  stated  objectives?" 
After  working  with  an  in-flight  refueling  instrumentation  panel  simulator,  can 
a  pilot  properly  operate  the  actual  panel  in  flight?  After  attending  a 
structured  demonstration  on  how  to  repair  a  radar  component,  can  a 
maintenance  technician  properly  repair  the  component? 

Having  expended  quite  a  few  resources  to  develop  your  CAI  program, 
you  probably  have  a  significant  investment  in  determining  whether  or  not  it 
functions  as  intended.  Since  instructor/leamer  receptivity  as  well  as  future 
resource  allocations  may  depend  on  the  demonstrated  effectiveness  of  this 
CAI  program,  it  is  definitely  worth  your  while  to  validate  the  courseware 
before  distributing  it  for  implementation. 

Section  F,  "Conducting  a  Validation  of  the  Instructional  System,"  AFP 
50-58,  Volume  IV,  describes  the  purpose  of  a  small-group  tryout,  how  to 
select  a  representative  sample,  and  how  to  analyze  the  results  for  validation 
purposes.  Whether  you  will  conduct  a  small-group  tryout  or  a  series  of 
individual  tryouts  depends  on  how  the  courseware  will  be  used.  If  the 
courseware  is  a  small-group  problem-solving  exercise  meant  to  enhance  an 
existing  lecture-based  course,  you  should  conduct  the  validation  in  a 
small-group  setting.  If  it  is  a  stand-alone  package  that  you  will  be  sending  to 
geographically  dispersed  users,  a  series  of  individual  tryouts  would  be  more 
appropriate. 

The  key  to  instructional  program  validation  is  the  validity  of  the 
instrument  you  use.  This  brings  up  test-item  validity  and  reliability,  detailed 
discussions  of  which  are  well  beyond  the  scope  of  this  document.  Note, 
though,  that  if  a  test  item  is  not  measuring  the  stated  objective,  learners  will 
not  be  tested  on  what  they  have  actually  gained  from  the  courseware.  As  a 
result,  the  courseware  may  appear  to  be  invalid,  but  the  validation  instrument 
is  actually  at  fault. 

Before  administering  the  courseware  to  a  group  or  individual  for 
validation  purposes,  make  sure  that  your  test  items  work  as  intended. 
Constructing  a  fairly  large  item  pool  to  start  with  in  ISD  Step  3.3  (so  you  will 
have  several  to  choose  from  and  refine)  and  then  conducting  item  analyses  on 
the  survey  tests  you  administered  in  ISD  Step  3.4  are  among  the  activities  that 
will  help  you  improve  item  validity. 
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Consult  the  test  and  measurement  texts  listed  at  the  end  of  this  section 
for  a  better  understanding  of  validation.  Section  4-5  of  AFP  50-58,  Volume 
III,  also  discusses  test  validity. 

Remember  throughout  the  validation  process  that  it  is  the  courseware 
that  is  being  validated,  not  the  learner.  Participants  of  small-group  and 
individual  tryouts  are  usually  much  more  relaxed  and  responsive  when  that 
fact  is  made  clear  to  them. 


6.7  Milestone  4:  Government  Acceptance 

Phase  IV  is  completed  upon  Government  acceptance  of  the  courseware 
and  its  ancillary  materials,  which  marks  Milestone  4.  The  acceptance  criterion 
stated  in  Section  4.2.3  of  MIL-T-29053B(TD)  requires  that  at  least  85  percent 
of  the  learners  shall,  on  their  first  attempt,  meet  the  standards  established  for 
each  objective.  Section  6-31,  AFP  50-58,  Volume  IV,  suggests  that  you 
continue  the  cycle  of  teaching,  testing,  analyzing,  and  modifying  "until  it  is 
proven  that  the  students  can  perform  to  the  level  specified  in  the  objectives 
and  tests."  Depletion  of  project  resources  might  dictate  an  earlier  cut-off 
point. 


You  will  probably  want  to  base  acceptance  criteria  on  the  characteristics 
of  the  topic  and  learners  at  hand.  If  the  topic  is  extremely  complex  and 
learners  need  only  have  a  limited  degree  of  familiarity  with  it,  perhaps  a  50 
percent  level  would  be  sufficient.  If  the  topic  is  fundamental  to  a  specialty 
code’s  primary  skill  set,  you  might  set  the  acceptance  criterion  at  100  percent. 
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Devereux,  Brian.  Why  didn't  you  tell  me  before?  CBT  the  first  time  around.  Data  Training. 
March  1986,  pp.  58-61 

Dick,  Walter  and  Cary,  Lou.  The  systematic  design  of  instruction.  2nd  ed.  Glenview,  IL:  Scott, 
Foresman,  1985. 

O'Neil,  Harold  F„  Jr.  Issues  in  instructional  systems  development.  New  York:  Academic  Press, 
1979. 

Stanley,  Julian  C.  and  Hopkins,  Kenneth  D.  Educational  and  Psychological  Measurement  and 
Evaluation.  Englewood  Cliffs,  NJ:  Prentice-Hall,  latest  edition. 

Thorndike,  Robert  L.  and  Hagen,  Elizabeth.  Measurement  and  Evaluation  in  Psychology  and 
Education.  New  York:  John  Wiley  &  Sons,  latest  edition. 

Yordy,  Laura.  How  do  you  know  if  it's  done?  Guidelines  for  reviewing  CBT  courses.  Data 
Training.  August  1986,  pp.  34-35. 
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Section  7.0 

Phase  V:  Implementation  and  Evaluation 


After  passing  Milestone  4,  Government  Acceptance  of  the  CAI  System, 
you  are  ready  to  implement  and  evaluate  the  courseware  and  its  ancillary 
materials.  Phase  V  is  comprised  of  three  steps,  as  shown  in  Figure  7-1. 

If  the  developing  agency  is  not  the  using  agency,  uncertainty  may  arise 
as  to  who  will  be  responsible  for  executing  these  steps.  As  noted  in  Section  3.8 
of  this  handbook,  transitioning  technology  is  often  the  weakest  link  in  the 
life-cycle  chain.  However,  if  the  agency  that  will  assume  responsibility  for 
implementation  and  maintenance  was  identified  in  the  CAI  Support  Plan 
(Section  3.8),  the  transition  from  Phase  IV  to  Phase  V  should  be  smooth. 


7.1  Step  1:  Distribute  Courseware 

If  the  CAI  system  is  to  be  incorporated  in  an  existing  course,  distribution 
involves  revising  the  syllabus  to  reflect  the  new  instructional  activity.  If  the 
CAI  system  is  to  be  distributed  in  a  stand-alone  format  to  geographically 
dispersed  learners,  the  logistics  become  more  complicated.  Your  distribution 
procedures  will  be  dictated  by  your  situation,  but  be  sure  to  record  the  name, 
office,  telephone,  and  address  of  each  recipient.  This  will  facilitate  future 
communications,  especially  for  course  update  purposes. 

The  critical  factors  for  either  of  the  above  scenarios  involve  the 
orientation  of  instructors  and  learners.  Sections  6-9  through  6-16,  AFP  50-58, 
Volume  IV,  provide  guidance  on  preparing  the  instructor  to  implement  the 
system.  Section  6-16  lists  information  that  is  particularly  useful  in  the 
instructor's  manual,  which  you  probably  included  in  Phases  II  and  III. 

Take  time  to  review  the  manual  with  the  instructor  as  part  of  your 
distribution  efforts.  If  the  CAI  system  is  a  stand-alone  package,  the  cover 
letter  should  include  a  point  of  contact  for  learners  who  may  have  suggestions 
or  problems. 


7.2  Step  2:  Conduct  Evaluation 

Section  6-3d,  AFM  50-2,  outlines  the  rationale  for  conducting  field 
evaluations  and  interpretation  of  results:  "Properly  conducted  evaluation 
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Government  Acceptance 
of  CAI  System 


Figure  7-1.  Phase  V:  Implementation  and  Evaluation. 
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assures  a  steady  flow  of  pertinent  and  timely  information  for  use  in 
maintaining  the  quality  and  cost-effectiveness  of  an  instructional  system, 
(p.  6-7). 


Section  7/Phase  V 


Section  6-32,  AFP  50-58,  Volume  IV,  offers  high-level  guidance  on 
conducting  an  operational  tryout  and  implementation.  Section  6-32  of  that 
document  points  out  that  validation  occurred  in  a  vacuum:  "Instructional 
materials  must  be  evaluated  as  an  integral  part  of  the  total  system.  Until  now, 
individual  and  small-group  tryouts  validated  instruction  in  an  isolated 
environment,"  (p.  6-23). 

Many  of  the  review  issues  you  addressed  for  CAI  system  validation 
(Step  6  of  Phase  IV),  should  be  raised  again  at  this  point.  The  main  difference 
to  keep  in  mind  is  that  learners  are  participating  in  the  course  primarily  to 
acquire  job-related  skills  and  knowledges.  Meeting  your  evaluation 
requirements  is  a  secondary  consideration  for  instructors  and  learners. 


7.3  Step  3:  Prepare  Recommended  Revisions  Report 

The  Recommended  Revisions  Report  constitutes  the  final  product  of  your 
CAI  procurement  effort.  At  a  minimum,  the  report  should  include: 

•  Executive  overview 

•  Brief  course  description 

•  Specific  strengths 

•  Specific  weaknesses 

•  Learners’  overall  rating 

•  Instructors’  overall  rating 

•  Evaluators'  overall  rating 

•  Recommended  revisions  (prioritized) 

•  Summary 

As  you  write  this  report,  remember  that  it  will  also  provide  input  for  the 
first  product  of  any  future  courseware  revision.  To  facilitate  that  effort  as  well 
as  make  this  report  as  effective  as  possible,  explain  terms  and  acronyms  fully. 
Also,  use  graphics  and  give  examples  of  specific  strengths  and  weaknesses. 


7.4  Milestone  5:  Government  Acceptance  of  Recommended 
Revisions  Report 

Government  acceptance  of  the  Recommended  Revisions  Report  marks 
completion  of  your  CAI  system  design,  development,  and  implementation 
effort.  It  would  be  helpful  to  debrief  development  team  members  and  other 
participants  for  ideas  on  how  to  improve  your  collective  performance  next 
time. 
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Section  7 
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Pergamon  Press 
Maxwell  House 
Fairview  Park 
Elmsford,  NJ  10523 

Data  Training 
38  Chauncy  Street 

Boston,  MA  021 1 1  (Data  Training  also  sponsors  conferences) 

Educational  Technology 
720  Palisade  Avenue 
Englewood  Cliffs,  NJ  07632 

Electronic  Learning 
902  Sylvan  Avenue 
Englewood  Cliffs,  NJ  07632 

Government  Computer  News 
1620  Elton  Road 

Silver  Spring,  MD  20903  (Free) 

MASS  High  Tech  Subscriptions 
755  Mt.  Auburn  Street 
Watertown,  MA  02172  (Free) 

T.H.E.  Journal  (Technological  Horizons  in  Education) 
Circulation  Department 
PO  Box  15126 
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Training 

731  Hennepin  Avenue 
Minneapolis,  MN  55403 

Training  News 
38  Chauncy  Street 
Boston,  MA  021 1 1 

Training  &  Development  Journal 

American  Society  for  Training  and  Development  (ASTD) 
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Suite  305 
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1015  15th  Street  NW,  Suite  901 
Washington,  DC  20005 
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1 1  West  42nd  Steeet 
New  York,  NY  10036 

Both  sponsor  sessions  at  annual  ACM  conferences  and  publish  the 
SIGCUE  Bulletin  and  the  SIGCHI  Bulletin. 

Greater  Boston  SIGCHI  information: 

Membership:  Newsletter: 

Mike  Dean  Dr.  Linda  M.  Evers,  3E-281 
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10  Moulton  Street  60  Frontage  Road 
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Systems  (ADCIS) 

Gordon  Hayes,  Executive  Secretary 
158  Bond  Hall 

Western  Washington  University 
Bellingham,  WA  98225 
(206)  767-2860 
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(202)  466-4780 

AECT  meets  annually  and  publishes  Educational  Communications 
Technology  Journal,  Journal  of  Instructional  Development,  and 
Instructional  Innovator. 
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Association  for  Educational  Data  Systems  (AEDS) 

1201  6th  Street,  NW 
Washington,  DC  20036 

AEDS  meets  annually  and  publishes  the  AEDS  Monitor  and 
AEDS  Journal. 


National  Society  for  Performance  and  Instruction  (NSPI) 

1 126  16th  Street,  NW 
Suite  315 

Washington,  DC  20036 
(202)  861-0777 

NSPI  meets  annually  and  publishes  the  Performance  &  Instruction 
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Society  of  Applied  Learning  Technology  (SALT) 

50  Culpeper  Street 
Warrenton,  VA  22186 
(703)  347-0055 

SALT  holds  numerous  conferences  and  workshops  on  CAI-related 
topics  and  sponsors  the  Journal  of  Educational  Technology  Systems. 


Technology  in  Training  &  Education  (TITE) 


Annual  conference  co-sponsored  by  Air  University,  the  USAF 


Academy,  and  Air  Training  Command 

March  16-20,  1987 

Colorado  Springs,  CO  80840-5751 

Lt  Col  Thomas  S.  Allman 
HQ  AU/XPZ 
Maxwell  AFB,  AL  36112 
(205)  293-6160  AV  875-6160 


Lt  Col  Robert  L.  James 
USAF  Academy/DFSR 
Colorado  Springs,  CO  80840-5751 
(303)  472-4195  AV  259-4195 
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Appendix  E 

Sample  Storyboard  Templates 


Appendix  E  contains  storyboard  templates  used  in  developing  "About 
AISIM,"  a  16-hour,  stand-alone,  self-paced  CAI  system  that  presently  runs  on 
an  IBM-PC.  Although  an  off-the-shelf  authoring  system  was  used,  these 
templates  were  designed  to  meet  the  informational  requirements  of  any  typical 
authoring  system.  They  may,  therefore,  be  considered  generic. 

This  set  was  used  in  preparing  the  "About  AISIM"  Final  Detailed  Design 
Report,  but  it  would  have  been  helpful  to  use  it  for  the  Draft  Detailed  Design 
Report  as  well.  Instead,  a  simplified  version  was  used  for  the  "About  AISIM" 
DDDR.  This  set  was  included  as  part  of  the  FDDR  deliverable  as  a  key  to  the 
screens  in  the  report. 
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Screen  Key 


* 


Al 1  Screens 

Screen  #  =  Screen  ID 

Section  =  Default  =  1;  most  authoring  systems  can 
segment  lessons  for  item  reporting 

Graphics  =  Y  (yes)  or  N  (no);  Y  means  bit-mapped  file 
associated  with  screen 


Screen  Type  - 

1  =  Presentation 

2  =  Multiple  Choice 

3  =  Matching 

Comments  =  Specific  information  for  the  screen 

Border  Color  =  1-8;  see  list  of  colors  below.  They  are 
painted  in  margins. 

Speed  =  Default  =  3;  advance  display  screen  by  full  pages  of 
text . 


Format  - 

1  Full  page  d  Right  half 

2  Top  half  5  Left  half 

3  Bottom  half 

Columns  =  Default  =2;  80  columns,  color  presentation 

Auto  Advan  e  =  Y  (yes)  or  N  (no);  Y  advances  to  next  frame 
after  "Delay";  N  advances  frames  only  after  student  response 

Delay  =  Number  of  seconds  "Delay"  before  Auto  Advance 


Colors  -  Foreground 
Background  1-8;  see 
Colors : 

1  =  Black 

2  =  Blue 

3  =  Green 

4  =  Cyan 

5  =  Red 

6  =  Magenta 


=  1-16;  see  list  below 
list  below 


7  =  Brown 

8  =  Light  gray 

9  -  Dark  gray 

10  -  Light  blue 

11  =  Light  green 

12  =  Light  cyan 


13  =  Light  red 

14  =  Light  magenta 

15  =  Yellow 

16  =  White 


*  This  key  is  intended  to  be  generic  and  represents  what 
most  authoring  systems  will  do. 
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p 


Presentation  Screen 

Unit  name:  *  Uni 

Section:  * 


Screen  #:  * 
Section:  1  © 

Graphics:  N  © 
Screen  Type:  1© 


Border  color:  *  © 
Speed:  3 

Format:  1  © 

Columns:  2  © 

Auto  Advance:  N  © 
Delay:  0  © 


Comments:  *  © 

0  1  2  3  4  5 


<space>  =  continue  s  =  stop 

Foreground  Color:  8©  Background  Color:  1© 

Next  Screen  #:  * 
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#  * 


t  No. :  * 


6  7  8 


I 


Presentation  Screen  -  Unique  Parameters 

(T)  Next  Screen  #  =  Indicates  which  destination  the  screen 
must  branch  to 
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Presentation  Screen 


Unit  name:  * 
Section:  * 


Unit  No. :  * 


Screen  #:  * 
'Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments:  * 

0  12 


Border  color:  * 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


3  4  5  6 


7 


8 


<space>  =  continue  s  =  stop 


Foreground  Color:  8  Background  Color:  1 

Next  Screen  #:  *© 
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Multiple-Choice  Screen 

©  Reporting  =  Y  (yes)  or  N  (no);  Y  means  record  student  responses 
on  lesson  diskette 

(2)  Number  of  Answers  (2-6)  =  Number  of  answer  alternatives 

(5)  Correct  Answer  (A-F,0)  =  Anticipated  "Correct"  alternative 
or  Null  ( 0 ) 

(4)  Go  to  A  -  F  =  The  branching  destination  for  each  alternative 
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MC 


Multiple  Choice  Screen 


Unit  name:  * 
Section:  * 


Unit  No.:  * 


Screen  #:  * 
•Section:  1 
Graphics:  N 
Screen  Type:  2 
.Reporting:  Y  0 


Border  color:  * 

Speed:  3 
Format:  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


Comments:  * 

01234567 


Enter  your  choice  (A-F)  _ 

<space>  =  continue  s 


stop 


Foreground  Color:  8 

Number  of  Answers  (2-6) :  *  © 

Correct  Answer  (A-F,0) :  *  © 


Background  Color: 
Go  to:  A:  *  © 

B 
C 
D 
E 
F 


1 
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©  Matching  Screens 
© 


© 

© 


Reporting  =  Y  (yes)  or  N  (no);  Y  means  include  student 
responses  on  lesson  diskette 

Number  of  Correct  Matches  (2-6)  =  Number  of  answers 

Correct  Answer  (A-F,0)  =  Anticipated  correct  sequence; 
e.g.,  1=A,  2=C,  3=D  expressed  as  "A,C,D" 

Go  to  =  Destination  screen  for  correct  answer 

Alternative  Combinations  =  Other  anticipated  sequences 
(not  used) 


(6)  Go  to  for  "Alternative  Combinations"  =  Destination 
for  other  anticipated  sequences  (not  used) 


screen 


© 


Otherwise  (Incorrect  Sequences)  =  Default  =  all  possible 
sequences  not  already  specified  in  branching 


(§)  Go  to  for  Otherwise  =  Destination  screen  for  possible 
sequences  not  already  specified  in  branching 


E-8 


MA 


#  * 


Matching  Screen 


Unit  name:  * 
Section:  * 


Unit  No. :  * 


Screen  #:  * 
Section:  1 
Graphics:  N 
Screen  Type:  3 
Reporting:  Y  0 


Border  color:  * 

Speed:  3 
Format:  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


Comments:  * 

012345678 


Enter  your  answer 
1  _  2  _  3  _  4_  5_  6_ 

Are  answers  OK?  (y/n) 

<space>  =  continue 

Foreground  Color:  8 
Number  of  Correct  Matches  (2-6) : 
Correct  Answer  (A-F,0):  * 
Alternative  Combinations:  NA 
Otherwise  (Incorrect  Sequences): 


s  =  stop 


Background  Color: 

1 

*0 

Branches 

0 

Go 

to: 

* 

o 

© 

Go 

to: 

NA 

© 

*  0 

Go 

to: 

* 

© 

E-9 


Appendix  F 

Sample  Screen  Design  Standards 


Appendix  F  contains  the  screen  design  standards  developed  for  "About 
AISIM,"  a  16-hour,  stand-alone,  self-paced  CAI  system  that  presently  runs  on 
an  IBM-PC.  Appendix  E  contains  detailed  information  on  what  each  element  of 
the  screen  template  means. 

The  structure  of  this  document  is  based  on  the  skeleton  of  each  unit 
(Section  1)  and  increasing  levels  of  detail  (Sections  2  and  3).  Section  l's 
primary  audience  is  the  typists  who  will  input  text  into  word-processing  Files 
or  into  the  authoring  system's  word  processor.  (To  be  efficient,  the  typists  need 
quick  access  to  explicit  directions.)  Section  2  is  provided  for  the  courseware 
developers'  reference  in  Phases  13  through  IV  as  well  as  for  the  quality 
assurance  tester's  and  the  authoring-system  programmer's  use  in  Phase  IV. 
Section  3  supports  activities  of  the  courseware  developers,  technical  editors, 
and  reviewers  in  Phases  II  through  IV. 
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"About  AISIM" 
Screen  Design  Standards 


For  more  information  contact: 
Maida  Eisenberg 
x!259 


or 

Linda  Evers 
x!257 
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Basic  Screen  Types  and  Standard  Screens 


Section  1 


This  section  contains  the  three  basic  types  of  screens  used  in  the  course.  It  also  includes 
samples  of  screens  that  should  appear  in  Units  2-14. 


1.1  Basic  Screen  Types 

All  story  boards  are  either  "presentation"  or  "interactive"  screens.  Each  type  of  screen  is 
described  below  and  accompanied  by  a  sample. 


1.1.1  Presentation  Screens 

Use  a  presentation  screen  when  the  user  does  not  need  to  make  any  responses.  Limit  text  on  a 
presentation  screen  to  a  maximum  of  24  lines.  Below  is  a  sample  presentation  screen.  Use  the  margin 
conventions  indicated  on  the  sample.  Include  a  header  in  the  upper  right-hand  corner  on  most 
presentation  screens  to  tell  the  user  what  section  of  the  unit  he  or  she  is  in.  Omit  headers  on  screens  that 
are  section  title  or  additional  documentation  screens. 
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ScLlion  1 


I'NUIUJX 


Presentation  Screen-No-Box 


Unit  nane:  Unit  No.: 

Sect  ion: 


Screen  I: 
Sec  t ion : 
Graphics : 
Screen  Type 


Border  color 
Speed : 

Format : 
Columns : 

Auto  Advance 
Delay 


Comments :  /*» 

0  ig)  , 

(*£“♦”" ' 

V. _ /  Second,  you  specify  the 

entity's  parameter  values 
with  that  form. 

Unlike  the  Process  Editor 
‘  Interface,  the  DUI  does 
not  produce  flowcharts  or 
plots . 

Statistics  on  entity 
behavior  are  presented  in 
AISIM’s  output  listing. 
Unit  14,  "Obtaining  AISIM 
Output,"  addresses  this 
in  deta 1 1  . 


! . _ ! 


<spacc>  =  continue  s  *  stop 

Foreground  Color:  Background  Color: 

Next  Screen  I  : 


•  Margins 

top  -  Line  2 
bottom  -  Line  22 
left  -  Space  10 
right  -  Space  70 

header  -  right  justify  to  Space  79 
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1.1.2  Interactive  Screens 

Interactive  screens  include  multiple-choice  and  matching  screens.  Use  interactive  screens  for  all 
screens  where  the  user  must  answer  a  question  or  make  a  decision.  This  includes  matching  question, 
multiple-choice  question,  unit  menu,  and  exit  screens.  Limit  interactive  screens  to  20  lines  of  text.  Use 
headers  for  multiple-choice  and  matching  question  screens.  Omit  headers  for  unit  menu  or  exit  screens. 
Sample  multiple-choice  and  matching  screens  with  the  margins  indicated  on  the  graphic  follow. 
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Multiple-choice 


*  12.125 


Multiple  Choice  Screen 

Unit  name :  Running  the  Simulation  with  the  AUI  Unit  No.:  12 

Section:  Self-Test 


Screen  #:  125 
Section:  1 
Graphics:  N 
Scree n  Type :  2 
Kepor  ting:  Y 


Border  color:  8 
Speed:  3 
Format:  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


A.  Pre-run 

B .  Mi  1- run 

C.  Post-run 

D.  Mid-  and  Post-run 


F.nter  your  choice  (A-D) 

<space>  =  continue  s  =  stop 


Foreground  Color:  8 

Background 

Color 

Number  of  Answers  (2-6):  4 

Go  to:  A: 

127 

Correct  Answer  (A-F,0):  C 

n : 

127 

C: 

126 

D: 

127 

B  : 

F  : 

F-e 


•  Margins 

top  -  Line  2 
bottom  -  Line  20 
left  -  Space  10 
right  -  Space  39 

header  -  right  justify  to  Space  79 


Section  l 


Matching  Screens 


MA 


»  2.68 


Matching  Screen 

Unit  name:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Self-Test 


Screen  # :  68 
feet  ion:  1 
Graphics:  N 
:'t’rnon  Type:  3 
Reporting;  Y 


Border  color:  8 
Speed:  3 
Format:  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


Ccnme  nt 
0 


& 


01  2  3  (j?  4  Q)  5  6  8 

Self -Testw 


Match  the  interface  with  its 
f  unc  t  ion  : 

1.  ___  Run  the  simulation 

2.  Document  the  model 
Processes 

3.  Design  and  construct 
the  mode  1 

4.  _  Save  models  and 

submodels  for 
subsequent  runs 


A. 

B. 

C. 

D. 

E . 


Hardcopy  (HUI) 
Replot  (RUI) 
Library  tLUI) 
Design  (DU I) 
Analysis  (AUI) 


View  plots  from  different 
model  runs 


Fnter  your  answer 
1_  3  4_ 

Are  answers  OK?  (y/n) 


<space>  =  continue 

s  *  stop 

Foreground  Color:  8 

Background  Color: 

1 

Number  of  Correct  Matches  (2-5): 

1 

Branches 

Correct  Answer  (A-E,l)s  E,A,D,C, 

f  B 

Correct:  Go 

to : 

69 

Alternative  Combinations:  NA 

Co 

to: 

NA 

Otherwise  (Incorrect  Sequences): 

* 

Incorrect:  Go 

to: 

70 

F-l  0 


Section 


*  Margins 

top  -  Line  2 
bottom  -  Line  20 
left  -  Space  10 
right  -  Space  70 

header  -  right  justify  to  Space  79 

other  margins  -  see  diagram  of  screen  above 
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1.2  Standard  Screens 

Units  2-14  contain  a  number  of  standard  screens.  In  addition,  Units  4-14  contain  standard 
screens  related  to  the  COMMSYS  example.  The  table  below  lists  these  standard  screens,  and  indicates 
whether  they  are  presentation  (P),  multiple-choice  (MC),  or  matching  (MA)  screens).  The  following 
pages  contain  samples  of  each  screen  and  list  the  standards  that  apply  to  it. 


Standard  Screen  Screen  Type 

Title  (Screen  1)  P 

Title  (Screen  2)  P 

Overview  P 

Unit  Menu  MC 

Conceptual  Overview  (Screen  1)  P 

Conceptual  Overview  (Screen  2)  P 

Applying  the  Concepts  (Screen  1)  P 

Applying  the  Concepts  (Screen  2)  P 

The  COMMSYS  Example  (Screen  1)  P 

The  COMMSYS  Example  (Screen  2)  P 

Unit  Summary  (Screen  1)  P 

Unit  Summary  (Screen  2)  P 

Additional  Documentation  P 

Self-test  (Screen  1)  P 

Self-test  (Screen  2)  P 

Closure  P 

Exit  MC 

Multiple-choice  Question  MC 

Multiple-choice  Answer  P 

Matching  Question  MA 

Matching  Answer  P 
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1.2.1  Title  (Screen  1) 


PNOBOXHB 


•  2.2 


Presentation  Screen- No- Box-Horizontal-Bottom 

Unit  name:  User  Interfaces:  Tho  Framework  of  AISIM  Unit  Mo.:  2 
Section:  Introduction 


Screon  •  :  2 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Border  color:  2 
Speed :  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


6 


7 


1 


i 


8 


< space >  -  continue  s *  *  stop 


Poce^roued  Color:  I  Oecfcf  round  Color •  1 

Moat  Screen  #  t  3 


•  Included  in  every  unit 

•  Logo  in  top  half 

•  Blank  bottom  half 

•  No  heading  in  upper  right-hand  comer  of  this  screen 

•  Margins 

top  -  Line  2 
bottom  -  Line  10 
left  -  Space  10 
right  -  Space  52 
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Section  l 


1.2.2  Title  (Screen  2) 


PMOBOXHB 


•  2.2 


Presentation  Screen- Mo- Box-Horizontal- Bottom 

Unit  name:  User  Interfaces:  The  Framework  of  AISIM  Unit  Mo.:  2 
Section:  Introduction 


Screen  I :  2 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Border  color:  2 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance :  N 
Delay:  0 


Foreground  Color:  B  Background  Colon  1 

Next  Screen  I i  3 


•  Included  in  every  unit 

•  Logo  in  top  half  of  screen 

•  No  heading  in  upper  right-hand  comer  of  screen 
•Type  title  in  First  box  on  bottom  half  of  screen 

Capitalize  initial  letters  in  all  except  prepositions,  conjunctions,  and  articles 
Center  in  box 

•  Type  unit  number  in  second  box  of  bottom  half  on  screen 

Use  number  rather  than  word 

Capitalize  First  letter  in  unit 
Center  in  box 
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Section  1 


•  Margins 

top  -  Line  2 
bottom  -  Line  22 
left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 


F-l  5 


Section  1 


1.2.3  Overview 


PNOBOX 


»  2.3 


Presentation  Screen-No- Box 


Unit  nane :  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Introduction 


Screen  1 :  3 
Section:  I 
Graphics:  N 
Screen  Type: 


Border  color:  2 
Speed:  3 


Format:  1 
Colunne:  2 


Auto  Advance:  N 
Delay:  0 


Overview 


5 


6 


7 


8 


Unit  1  introduced  the  functions  and  products 
of  AISIM,  an  interactive  simulation  modeling 
tool.  The  purpose  of  this  unit  is  to 
introduce  you  to  concepts  you  will  need  to 
understand  and  use  AISIM. 

This  unit  will  focus  specifically  on  AISIFPs 
five  main  user  interfaces.  These  interfaces 
enable  you  to  build  and  analyze  simulation 
models  without  the  help  of  a  programmer. 


<epace>  •  continue  ■  -  stop 


Background  Color:  1 


Next  Screen  I:  4 


•  Included  in  Units  2-14 

•  No  heading  in  upper  right-hand  comer 

•  Most  overviews  contain  the  following  three  elements: 

purpose  of  unit 

what  previous  units  contain 

how  the  unit  meets  the  purpose  stated 

•  Margins 

top  -  Line  2 
bottom  -  Line  22 
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Section  1 


left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 
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Section  1 


1.2.4  Unit  Menu 


Multiple  Choice  Screen 

Unit  nans:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Introduction 


Screen  #:  4 
Section:  1 
Graphics:  N 
Screen  Type:  2 
Reporting:  Y 


Border  color:  2 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


Enter  your  choice  (A-E)  _ 

<epace>  •  continue  *  ■  atcy 


Foreground  Color:  9 
Number  of  Ansvere  (2-5):  * 
Correct  Answer  (A-E,0):  * 


Background  Color:  1 
Go  to:  A:  5 
B:  22 
C:  55 
D:  66 
E:  89 
ri 


•  Included  in  Units  1-14 

•  See  example  for  exact  wording  and  format  of  first  paragraph 

•  Skip  a  line  and  type  options: 

introduce  each  option  with  a  capital  letter  followed  by  a  period 
skip  a  space  between  each  option 

capitalize  initial  letter  of  all  words  except  prepositions  and  conjunctions 

•  Margins 

top  -  Line  2 
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Section  1 


bottom  -  Line  20 
left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 


Section  1 


1.2.5  Conceptual  Overview  (Screen  1) 


PNOBOX 


•  2.5 


Presentation  Screen-No- Box 

Unit  nane :  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Conceptual  Overview 


Screen  9:  5 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Border  color:  8 
S  pe  e  d  :  3 
Format:  1 
Columns:  2 
Auto  Advance:  Y 
Delay:  0 


<space>  “  continue  e  *  stop 


Foreground  Colon  i  Background  Color:  1 

Next  Screen  f:  6 


•  Included  in  Units  2-14 

•  Text  in  box  should  read: 

Conceptual  Overview 

•  Capitalize  initial  letters  in  "Conceptual  Overview" 

•  Margins: 

top  -  Line  2 
bottom  -  Line  10 
left  -  Space  10 
right  -  Space  52 

other  margins  -  see  diagram  of  screen  above 
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Scclion  1 


1.2.6  Conceptual  Overview  (Screen  2) 


PNOBOXHB 


•  2.6 


Presentation  Screen-No- Box-H or izontal-Bot ton 

Unit  nanei  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Conceptual  Overview 


Screen  t:  6 
Section:  1 
Graphics:  N 
Screen  Type:  l 


Border  colors  8 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 


AISIM  ie  e  software  tool  that  can  help  you  build  end 
run  diecrete-event  eimuletion  models.  This  section 
describee  the  five  main  AISIM  user  interfaces  with 
which  you  will  build,  debug,  end  verify  models, 
then  run  eimuletione  of  those  models. 


<epece>  •  continue  s  *  stop  stop 


Foreground  Color:  4  Background  Color:  1 

Vest  Screen  #:  7 


•  Included  in  Units  2-14 

•  Follows  Conceptual  Overview  (Screen  1) 

•  Repeat  box  and  text  in  top  half 

•  Margins 

top  -  Line  2 
bottom  -  Line  22 
left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 
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Section  1 

1.2.7  Applying  the  Concepts  (Screen  1) 


PMOBOX 


*  2.22 


Presentation  Screen-No-Box 


Unit  name:  User  Interfaces:  The  Franework  of  AISIM  Unit  No.:  2 
Section:  Applying  the  Concepts 


Screen  ft  22 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  1  2 


Border  color:  4 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  Y 
Delay:  0 


3  4  5  6  7  8 


Applying  the  Concepts 


<space>  •  continue  s  •  stop 


Foreground  Colon  8 
Scr*-  R-mo  «t  23 


Background  Color:  l 


•  Included  in  Units  2-14 

•  Text  in  box  should  contain  Applying  the  Concepts 

capitalize  initial  letter  in  each  word 
see  Conceptual  Overview  for  margins 
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Section  1 


1.2.8  Applying  the  Concepts  (Screen  2) 


PNOBOXHB 

•  2.23 

Presentation  Scree n-No-Box-Hor 1 zontal-Bot ton 

Unit  nine:  User  Interfacesi  The  Framework  of  AISIM  Unit  No. i  2 
Section:  Applying  the  Concepts 


Screen  I:  23 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Conme  n  t  s : 

0  1  2  3  4  5  6  7  8 


Applying  the  Concepte 


Thle  eectlon  flret  exploree  the  functions  of  AISIH'e  five 
major  ueer  lnterfecee,  then  dlecueeee  the  relat lonehlpe 
among  then. 


<epaoe>  ■  continue  4  »  stop 


Foreground  Color:  9"  Beckground  Color:  1 

Next  Screen  •:  24 


Border  color:  4 
Speed:  3 
Forraetj  3 
Columns:  2 
Auto  Advence:  N 
Delay:  0 


•  Included  in  Units  2-14 

•  Follows  Applying  the  Concepts  (Screen  1) 

•  Repeat  box  from  previous  screen  in  top  half 

•  Text  in  bottom  half 

•  See  Conceptual  Overview  for  margins 
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Section  1 


1.2.9  The  COMMSYS  Example  (Screen  1) 


PNOBOX 


I  10.51 


Presentation  Screen-No-Box 

Unit  name:  Defining  Entities  with  the  DUI  Unit  No. s  10 

Section:  The  COMMSYS  Example 


Screen  #:  51 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  1  2 


Border  color:  2 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  Y 
Delay:  0 


3  4  5  6 


7  8 


<space>  -  continue  •  ■  stop 


Foreground  Color:  8  Background  Colon  1 

Next  Screen  I:  52 


•  Appears  in  Units  4-14 

•  COMMSYS  in  all  capital  letters 

•  See  Conceptual  Overview  for  margins 
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1.2.10  The  COMMSYS  Example  (Screen  2) 


PNOBOXHB 


Presentation  Screen-No-Box-Horizonta 1 -Bottom 


#  10.52 


Unit  name:  Defining  Entities  with  the  DUI  Unit  No.:  10 

Section:  The  COMMSYS  Example 


Screen  I:  52 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  l  2 


Border  color:  2 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


3  4  5  6 


7  8 


You  created  the  COMMSYS  architecture  in  Unit  8, 
"Defining  Architecture  with  the  ADE,"  and  defined 
the  Processes  for  that  system  in  Unit  9,  "Defining 
Processes  with  the  PEI." 

The  last  step  in  building  an  AISIM  model  of  COMMSYS 
is  to  define  the  remaining  entities. 

This  section  demonstrates  how  to  apply  the  Design 
User  Interface  (DUI),  which  was  introduced  in  Unit  4. 


<space>  ■  continue  3  *  stop 


Foreground  Color:  8  Background . Co  lor :  1 

Next  Screen  •:  53 


•  Follows  COMMSYS  (Screen  1) 

•  Repeat  box  from  previous  screen  in  top  half 

•  Begin  text  in  bottom  half  on  Line  15 

•  See  Conceptual  Overview  for  margins 
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1.2.11  Unit  Summary  (Screen  1) 


PNOBOX 


♦  2.55 


Presentation  Screen-ffo-Box 

Unit  nane:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Unit  Summary 


Screen  ♦:  55 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  12  3 


Border  color:  5 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance :  Y 
Delay:  0 


4  5  6  7 


a 


<space>  ■  continue  *  ■  stop 


Foreground  Color:  8'  Background  Colon  1 

Next  Screen  •:  56 


•  Included  in  Units  2-14 

•  Repeat  box  from  previous  screen  in  top  half 

•  Capitalize  initial  letter  of  each  word 

•  See  Conceptual  Overview  for  margins 
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Section  1 


1.2.12  Unit  Summary  (Screen  2) 


PNODOXH  B 


*  2.56 


Prose ntation  Screen-No-Box-Hor t zontal-Bot ton 

Unit  nano:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Unit  Sumnary 


Screen  4  :  56 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Conment s : 

0  12  3 


Border  color:  7 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance :  N 
Delay:  0 


4  5  6  7 


8 


Unit 


ary 


This  unit  addressed  three  major  points. 


<spac«>  -  continue  •  ■  stop 


Foreground  Color:  b  Background  Color:  1 

Next  Screen  I:  57 


•  Included  in  Units  2-14 

•  Follows  Unit  Summary  (Screen  1) 

•  Standard  screen  with  top  half  as  shown 

•  Text  in  bottom  half  as  shown 

•  See  Conceptual  Overview  for  margins 
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1.2.13  Additional  Documentation 


PHB 


I  2.64 


Presentation  Screen-Horizontal- Bottom 

Unit  nane:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Unit  Sunnary 


Screen  • :  64 
Section:  1 
Graphics:  M 
Screen  Type:  1 


Border  color:  5 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 


Foreground  Colon  8  Background  Colon  1 

Next  Screen  It  65 


•  Included  in  Units  2-14 

•  Center  title  in  box 

•  See  example  above  for  sample  wording 

•  Cite  the  references  as  follows: 

AISIM  User's  Manual 
AISIM  Course  Guide 

•  Capitalize  initial  letter  of  each  word  in  title 

•  Margins 

top  -  Line  2 


F-2  8 


Section  1 


bottom  -  Line  22 
left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 


F.- 29 


1.2.14  Self-Test  (Screen  1) 


Section  1 


PNOBOX 


*  2.66 


Unit  name:  User  Interfaces 
Section:  Self-Test 


Screen  I :  66 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  1  2 


Presentation  Sc reen-fio- Box 
:  The  Framework  of  AISIM 


Border  color:  8 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  Y 
Delay:  0 


3  4  5 


Unit  No.  :  2 


6  7  9 


Self-Teet 


<apace>  ■  continue  s  -  stop 

Foreground  Color:  •  Background  Color:  l 

Nest  Screen  ft  67 


•  Included  in  Units  2-14  exactly  as  shown 

•  Center,  capitalize  initial  letters,  and  hyphenate  Self-Test  within  box  as  shown 

•  See  Conceptual  Overview  for  margins 
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1.2.15  Self-Test  (Screen  2) 


PNOBOXHB 


*  2.67 


Presentation  Screen-No* * Box -Hor i zontal- Bottom 

Unit  name:  User  Interfaces:  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Self-Test 


Screen  f:  67 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comma  nt  s : 

0  1  2 


Border  color:  8 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


3  4  5  6 


7 


a 


The  following  five  questions  in  this  eelf-test 

give  you  the  chance  to  asaesa  your  mastery  of  AISIM's 

user  interfaces. 

For  best  results,  answer  the  questions  and  review  the 
sections  listed  on  the  feedback  screens. 


<space>  -  continue  s  -  stop 


Foreground  Colon  I  Background  Color:  1 

Next  Screen  •:  (8 


•  Included  in  Units  2-14 

•  Follows  Self-Test  (Screen  1) 

•  Center,  capitalize  initial  letters,  and  hyphenate  Self-Test  within  box  as  shown 

•  Text  below  box  specifies  the  topic  covered  in  the  unit 

•  See  Conceptual  Overview  for  margins 
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1.2,16  Closure 


PNOBOX 


»  10.50 


Presentation  Screen-No-Box 


Unit  name:  Defining  Entities  with  the  DUI 
Section:  Applying  the  Concepts 


Unit  No.;  10 


Screen  I:  50 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  1 


Border  color:  4 
Speed:  3 
Format:  1 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


This  concludes  applying  the  concepts  for  "Defining 
Entities  with  the  DUI.'’  Press  the  space  bar  to 
return  to  the  unit  menu. 


<space>  »  continue  s  •  stop 


Foreground  Color:  8 
Next  Screen  I:  5 


Background  Color:  1 


•  Included  in  Units  2-14 

•  End  the  Conceptual  Overview,  Applying  the  Concepts,  the  COMMSYS  Example,  the  Unit 

Summary,  and  the  Self-Test  with  a  closure  screen 

•  Top  half  with  box  containing  the  name  of  the  section 

•  Center  text  in  box  on  top  half 

•  Bottom  half  specifies  the  section  name  and  the  unit  name.  See  the  sample  for  exact  wording 

•  See  Conceptual  Overview  for  margins 
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1.2.17  Exit 


MC 


Multiple  Choice  Screen 

Unit  nanat  User  Interfaces:  The  Franework  of  AISIM 
Section:  Exit 


I  2.89 


Unit  No.:  2 


Screen  ♦ :  89 
Section:  1 
Graphics:  N 
Screen  Type:  2 
Reporting:  Y 


Comme  nts : 

0  1 


Border  color:  5 
Speed:  3 
Format:  l 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


Exit 


You  are  now  exiting  Unit  2,  "User  Interfaces:  The 
Framework  of  AISIM. ■  The  next  unit  is 
•Understanding  AISIM's  Modeling  Constructs.* * 

A.  Return  to  this  unit's  menu 

B.  Exit  from  this  unit 


Enter  your  choice  (A-B) 


<space>  -  continue 


stop 


Foreground  Color:  8 
Number  of  Answers  (2-2)  i  2 
Correct  Answer  (A-B,0) :  A , B 


Background  Color:  1 
Go  to:  A:  4 

B:  Out 
C: 

D: 

E: 

F: 


•  Included  in  Units  2-14 

•  Center  title  in  box  and  capitalize  initial  letter 

•  Use  the  exact  text  shown  in  the  sample.  Specify  the  unit  number,  tide,  and  tide  of  the  next 

unit 

•  See  Unit  Menu  for  margins 
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1.2.18  Questions  and  Answers 

Two  types  of  questions  appear  in  this  course:  interactive  and  self-test. 

Interactive  questions  occur  in  the  Conceptual  Overview,  Applying  the  Concepts,  and 
COMMSYS  Example  sections.  Interactive  questions  have  two  answer  screens:  correct  and  incorrect. 
Below  is  a  flow  chart  of  the  sequence  of  interactive  question  and  answer  screens: 


Next 

Screen 


Self-test  questions  occur  only  in  the  Self-test.  They  have  three  answer  screens:  correct, 
incorrect  with  a  hint,  and  incorrect  with  a  suggestion  to  review  the  material  that  the  question  tests. 
Following  is  a  flow  chart  of  the  sequence  of  self-test  questions  and  answers: 


Next 

Screen 


Both  interactive  and  self-test  questions  can  be  either  multiple-choice  or  matching.  Following 
are  sample  multiple-choice  and  matching  questions  and  answer  formats  with  the  appropriate  margins 
indicated. 
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Multiple-choice: 

Question 


ML 


•  12.125 


Multiple  Choice  Screen 

Unit  name:  Running  the  Simulation  with  the  AUI  Unit  No. :  12 

Section!  Self-Test 


Screo n  ft  125 
Section:  1 
Graphics:  N 
Screen  Type :  2 
Reporting:  Y 


Border  color i  8 
Speedi  3 
Formati  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


phase  of  the  AUI? 

A.  Pre-run 


B.  Mid-run 


C.  Post-run 

I).  Mid-  and  Post-run 


enter  your  choice  (A-D) 

<space>  =  continue  3  •  stop 

Foreground  Color:  0  Background  Color:  1 

Number  of  Answers  (2-6):  4  Go  to:  A:  127 

Correct  Answer  (A-F,0):  C  U:  127 

C:  126 
D:  127 
E  : 

F: 
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•  Number  each  question 

•  Start  question  at  Line  2 

•  Skip  a  line  after  the  question 

•  Identify  each  option  with  capital  letter  followed  by  a  period 

•  Capitalize  initial  letter  of  first  word  in  each  choice 

•  Skip  a  line  between  choices 

•  Margins 

top  -  Line  2 
bottom  -  Line  20 
left  -  Space  10 
right  -  Space  39 

header  -  right  justify  to  Space  79 
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Presentation: 

Answer  to  Multiple-choice 


•  Use  Presentation-Vertical-Right  screens  for  answers  to  multiple-choice  questions 

•  Put  questions  on  the  left  half  of  the  screen,  and  answers  on  the  right  half 

•  Put  "Incorrect"  or  "Correct"  in  center  of  box  .  Capitalize  initial  letter  of  "Incorrect"  or 

"Correct" 

•  Skip  a  line  after  box 

•  Do  not  use  quotation  marks  around  the  letter  of  the  answer.  Skip  two  spaces  and  begin 

explanation  of  answer.  Keep  left  margin  an  43 

•  Margins 
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top  -  see  diagram  of  screen  above 
bottom  -  Line  20 
left  -  Space  10 
right  -  Space  70 

other  margins  -  see  diagram  of  screen  above 
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Matching: 

Questions 


MA 


#  2.60 


Matching  Screen 

Unit  name:  User  Interfaces!  The  Framework  of  AISIM  Unit  No.:  2 
Section:  Self-Test 


Screen  I*.  68 
Section:  I 
Graphics:  N 
Screen  Type:  3 
Reporting:  Y 


Border  color:  8 
Speedi  3 
Format:  1 
Columns:  2 

Au to  Advance :  N 
Delay:  0 


Comments: 

01  2345678 


Self-Test 


Match  the  interface  with  its 
function: 

1.  _  Run  the  simulation  A. 

2.  _  Document  the  model  B. 

Processe  s 

C. 

3.  _  Design  and  construct 

the  model  D. 

4.  _  Save  models  and  E. 

submodels  for 
subsequent  runs 

5.  ___  View  plots  from  different 

model  runs 


Enter  your  answer 
2~ 

Are  answers  OK?  (y/n) 

<space>  *  continue  s  -  stop 


Hardcopy  (HUI ) 
Replot  (RUI) 
Library  (LUI) 
Design  (DU I) 
Analysis  (AUI) 


Foreground  Color:  8 
Number  of  Correct  Matches  (2-5): 
Correct  Answer  (A-E,l)r  E,A,D,C 
Alternative  Combinations:  NA 
Otherwise  (Incorrect  Sequences): 


Background  Color:  1 
1  Branches 


B 

Correct ; 

Go 

to: 

69 

Go 

to : 

NA 

* 

I ncorrect : 

Go 

to: 

70 

•  See  multiple-choice  question  for  margins 
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Presentation; 

Answers  to  Matching 


p 

I  2.69 

Presentation  Screen 

Unit  name:  User  Interfaces:  The  Framework  of 

AISIM 

Unit  No. : 

2 

Sec t ion :  Self 

-Test 

Sc reen  ff :  69 

Border 

color:  8 

Section:  1 

Speed : 

3 

Graphics:  N 

Format : 

1 

Screen  Type: 

1 

Columns 

i:  2 

Auto  Advance:  N 

Delay:  0 

Comments : 

0  1 

2  3 

4 

S 

6 

7  8 

Self-Test 

Match 

the  interface  with  its 

Cor  rec t 

function: 

1  .  E 

Run  the  simulation 

A . 

Hardcopy  (HUI) 

2.  A 

Document  the  model 

B. 

Replot 

(RUI) 

Processes 

C. 

Library 

(LUI) 

3.  D 

Design  and  construct 
the  model 

D. 

Design 

(  DU  I  ) 

4  .  C 

Save  models  and 

E . 

Analysis  ( AU I ) 

submodels  for 

subsequent  runs 

The  answers 

are  as  shown. 

5 .  B 

View  plots  from  different 

model  runs 

<space>  3  continue 

s  =  stop 

Foreground 

Color:  8 

Background 

Color:  1 

Next  Screen  1:  72 

•  Use  Presentation  screens  for  answers  to  matching  questions 

•  See  multiple-choice  answer  for  margins 


F-4  0 


Section  2 


Section  2 

Identification  and  Transfer  Information 

This  section  explains  the  information  listed  above  and  below  the  screen  on  each  story  board. 
Some  of  this  information  identifies  the  story  board  itself,  including  its  unit,  section,  page,  etc.  The  rest 
provides  directions  for  transferring  it  onto  the  authoring  system. 


2.1  Unit  Number 


PNOBOXHB 


I  2.2 


Unit  name 
Sec 1 1  on i 


Pre  se  nta t 

:  User  Interfaces 
I  n  troduc 1 1  on 


Ion  Screen-Mo- Box -Hor 1 zontal-Bot tom 


The  Framework  of  AISIM 


Unit  No. s  2 ‘ 


Screon  t  :  2 
Section:  l 
Graphics:  N 
Screen  Type:  i 


Comme  nt  s : 

0  1  2 


Border  color:  2 
Speed:  3 
format:  3 
Columns:  2 
Auto  Advance:  N 
Do  l a  y  :  0 


3  4  5  6  7 


1 

i 


<apace>  -  continue  3  »  stop 


foreground  Color:  9  Background  Colon  1 

Mont  Screon  it  3 


•  Appears  in  the  directions  above  every  screen.  Also  appears  on  the  title  screen  at  the 
beginning  of  each  unit 
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2.2  Unit  Title 


PNOBOXHB 


»  2.2 


Unit  name 
Sect  1  on i 


Presentation  Scree n- Mo- Box- Ho r l zontal- Bottom 


User  T  nter faces  : 
ntroduc t l on 


The  Framework 


of  AISIM 


Unit  Mo .  : 


2 


Screen  I :  2 
Sec  t Ion :  1 
Graphics:  N 
Screen  Type:  l 


Comme  nt  s : 

0  12  3 


Border  color:  2 
Speed :  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


4  5  6  7  8 


l 

i 

* 


ABOUT 


<space>  -  continue  s  »  stop 


Foreground  Colon  B  Background  Colon  1 

Next  Soreen  It  3 


•  Use  participal  phrase  (a  verb  ending  in  "ing")  whenever  possible.  For  example: 

Introducing  the  AISIM  Interfaces 

•  Keep  title  exactly  the  same  throughout  the  unit  in  top  screen  directions,  Unit  Menu,  Exit 

screen,  and  references  to  it  in  other  units  and  the  course  guide 

•  Capitalize  initial  letter  in  each  word  except  prepositions,  conjunctions,  and  articles.  For 

example: 

Introducing  the  AISIM  Interfaces 


F-4  2 
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•  Designate  unit  with  a  number,  not  a  word.  For  example: 

Unit  2 

•  Use  consistently  in  top  screen  directions  and  all  references 

•  Center  in  box  provided  on  unit  title  screen 
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Section  2 


2.3  Section  Name 


PH  B 


Pro'jent.ation  Scr<?r>n-H* *'  r  i  ■  i|  •  •  » 


Unit  name:  Vn**r  Interfaces: 
Section:  Conceptual  Overview 


fa 


Framework 


'  '  '  I  n 


Screen  # :  M 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Comments : 

0  1  2 


p^r'.or  ••  I  -r  •  A 

r>\ . i:  » 

Fo»  n-t  *  :  t 
f  O  1  unn  •:  :  ’ 

Auto  A  !  •"  ‘I 

I'*  1  »,■:  0 


3  -1 


6 

Concept ua 1 


Ove  r v  i 


Once  you  have  built  a  model  in  the  DM!,  you  run  a 
simulation  of  that  model's  performance  with  the 
Analysis  User  Interface  ( AU  I )  .  You  can  control 
the  run  and  view  Its  results  by  issuin')  commands 
in  this  user  Interface. 


<space>  *  continue  s  *  st' P 


Foreground  Color:  0  Background  Color:  1 

Next  Screen  •:  15 


•  Section  name  appears  in  directions  above  screen 

•  Abbreviate  section  name  as  a  header  in  upper  right-hand  comer  of  most  screens. 

Right  justify  header  to  Space  79 

•  Use  consistently  in  directions  above  screens,  headers,  and  all  other  references  to  section 

name. 

•  Include  the  following  sections  in  Units  2-14 

Introduction 
Conceptual  Overview 
Applying  the  Concepts 
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Section 


The  COMMSYS  Example  (Units  4-14) 

Unit  Summary 

Self-test 


Section  2 


2.4  Screen  Number,  Next  Screen  Number,  and  Go  To 


PNOBOXH  B 


•  2.2 


Presentation  Screen- Mo- Box -Hor i zon  t a l -  Bottom 


Unit  name:  User  Interface* *: 
Section:  Introduction 


Screen  •  :  2 
Section:  l 
Graphics:  N 
Screen  Type:  1 


The  Framework  of  AlSIft 


Unit  No.:  2 


Border  color:  2 
Speed :  3 
Format:  3 
Columns:  2 
Auto  Advance:  M 
Delay:  0 


Comments : 


0 


2  3  4  5 


6  7  8 


ABOUT 


Foreground  Color: 
Next  Screen  li  3^ 


Background  Colon  1 


•  Screen  Number 

Enter  screen  number  in  the  space  provided  at  top  of  the  page 
Number  all  screens  in  a  unit  consecutively,  starting  with  1 

•  Next  Screen  Number 

Most  screens  go  directly  to  the  next  number  (screen  2  follows  screen  1)  Enter  the  number 
of  the  next  screen  in  the  space  provided  at  the  bottom  of  the  page. 


F-4  6 


Seaton  2 


•  Go  To 

All  unit  menu,  multiple-choice  question,  matching  question,  and  exit  screens  can  branch  to 
multiple  screens.For  these  screens,  list  each  possibility  and  under  what  circumstances  the 
first  screen  would  branch  to  it.  For  example: 


Multiple  Choice  Screen 

Unit  name:  Running  the  Simulation  with  the  AUI  Unit  No. t  12 

Section:  Self-Teat 


Screen  #:  125 
Section:  1 
Graphics:  N 
Screen  Type:  2 
Reporting:  Y 


Comments : 

0  1  2 


Border  color:  8 
Speed :  3 
Format:  1 
Columns:  2 

Auto  Advance:  N 
Delay:  0 


3  4  5  6 


l)  In  the  COMMSYS  model,  once 
the  plots  have  been  defined, 
they  are  viewed  in  which 
phase  of  the  AU17 


7  8 

Self-Test 


A.  Pre-run 

B.  Mid-run 

C.  Post-run 

D.  Mid-  and  Post-run 


Enter  your  choice  (A-D)  _ 

<space>  a  continue  s  *  stop 


Foreground  Color:  8 

Background 

Color:  1 

Number  of  Answers  (2-6):  4 

Go  to:  A: 

X71* 

Correct  Answer  (A-F,0):  C 

B: 

127 

C: 

126 

D: 

127 

E  : 
Fi 
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2.5  Header 


PH  0 


2.U 


Presentation  Screcn-iiort *  *i»  =»  l  -  p*  •  •  *  « 

Unit  name:  User  Interfaces:  The  Framework  f  "nit  'Ir.  :  2 

Section:  Conceptual  Overview 


Screen  #:  14 
Section:  l 
Graphics:  N 
Screen  type:  l 


Comnents : 

0  l  2 


Rnr  f}o  r  -.1  M-  •  fl 

Sr— I:  1 
Form.it  :  * 

Column*::  1 
Auto  Ad*.  »••*:«*  *1 
n-'l.iy:  0 


3  4 


Conceptu 


. / 

•ptual  Overview^ 


Once  you  have  built  a  model  in  the  DU t ,  you  run  a 
simulation  o f  that  model^a  performance  with  the 
Analyals  Uaer  Interface  (AUI).  You  can  control 
the  run  and  view  lta  reaulta  by  lsauing  commands 
In  this  uaer  interface. 


<spsce>  -  continue  s  *  stop 


Foreground  Color:  0  Background  Color:  l 

Next  Screen  t  :  IS 


•  The  header  indicates  which  section  the  screen  appears  in.  It  sometimes  appears  in  an 

abbreviated  form.  For  example: 

Applying  Concepts 

•  Place  header  on  line  1,  in  the  upper  right-hand  comer,  right-justified  to  Line  79 

•  Use  consistently  throughout  units  and  course  guide 
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•  Headers  do  not  appear  on  screens  with  unit  or  section  titles.  For  example: 


PNOBOXHB 


2.2 


Presentation  Screen- No- Bo x- Horizontal-Bottom 

Unit  name:  User  Interfaces:  The  Framework  of  AISIM  Unit  Mo. s  2 
Sectloni  Introduction 


Screen  t  :  2 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Border  color:  2 
Speed :  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


Comme  nt s : 


0 


2  3  4 


5  6  7 


i 


9 


< space >  -  continue  %  -  stop 


Porogrouad  Color:  I  Background  Colon  1 

Moat  Screen  I i  3 
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Section  3 

General  Language,  Grammar,  and  Graphics  Conventions 

This  section  presents  and  illustrates  general  language,  grammar,  and  graphics  conventions  used 
throughout  "About  AISIM." 


3.1  Acronyms/Abbreviations 

•  For  first  reference  to  an  item  in  each  section,  use  the  complete  title  followed  by  the 
acronym  in  parentheses.  For  example: 

Analysis  User  Interface  (AUI) 

•  The  following  acronyms  are  standard  throughout  this  courseware: 

Communications  System  (COMMSYS) 

Production  System  (PRODSYS) 

Automated  Interactive  Simulation  Modeling  System  (AISIM) 


3.2  Punctuation 

•  Put  a  comma  or  a  period  inside  the  closing  quotation  marks.  Semicolons,  colons, 
question  marks,  and  exclamation  points  follow  the  closing  quotation  marks  unless  the 
mark  is  logically  part  of  the  quoted  material.  For  example: 

The  rule  of  thumb  is  "Like  dissolves  like." 

The  "solute,"  NaCl,  dissolves  in  the  "solvent." 

•  Do  not  hyphenate  words 
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Section 


3.3  Lists 


•  Use  bullets  for  lists  of  items  that  are  not  sequential.  For  example: 

The  cafeteria  menu  for  Tuesday  includes: 

•  Asparagues  with  Hollandaise  sauce  and  almonds 

•  Sirloin  steak 

•  Peanut  butter  and  jelly  sandwiches 

•  Use  numbers  for  sequential  or  step-by-step  lists.  For  example: 

To  run  the  copy  machine  do  the  following  in  order: 

1)  Turn  on  the  machine 

2)  Put  in  paper 

3)  Select  the  number  of  copies  desired 

4)  Press  "Start"  button 

•  For  both  lists 

Skip  a  line  between  stem  and  First  item  of  multiple-choice  questions 
End  stem  in  colon  if  it  is  an  incomplete  sentence 

Make  items  in  a  list  either  all  incomplete  sentences  or  all  complete  sentences 


3.4  Numbers 

•  Use  digits  if  the  number: 

Is  ten  or  more 

Refers  to  a  specific  value  on  the  screen.  For  example: 

See  Line  3  in  the  table 

•  Spell  out  the  three  words  for  a  whole  number  if  the  number: 
Begins  a  sentence 

Counts  Something,  as  opposed  to  measuring  it.  For  example: 
Answer  all  four  questions 
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Refers  to  something  that  already  contains  a  digit.  For  example: 

Two  3-sided  figures 

Is  a  large  number,  and  the  digit  is  cumbersome.  For  example: 

3  billion,  not  3,000,000,000 

Refers  to  an  approximation  rather  than  an  exact  count  or  measure.  For  example: 
The  system  contains  over  one  hundred  elements. 


3.5  Word  Conventions 

•  Use  the  following  words  consistently: 
unit  (not  module  or  lesson) 
section  (not  branch) 
user  interface  (not  interface) 
construct  (not  concept) 
issue  (not  use)  a  command 
enables  (not  allows) 
run  (not  execute) 


3.6  General  Style  Guidelines 

•  Use  the  active  voice  whenever  possible.  In  the  active  voice,  the  subject  performs  the 
action  the  verb  represents.  For  example: 

The  cat  clawed  its  way  up  the  balloon. 

•  Use  the  passive  voice  to  emphasize  the  receiver  of  the  action  or  when  the  doer  of  the 
action  is  unimportant  or  unknown.  For  example: 


F-52 


Section  3 


The  balloon  was  damaged. 

•  Whenever  possible,  write  in  the  present  tense,  not  the  past 

•  Use  the  second  person  ("you")  when  addressing  the  student.  Never  use  "let's"  or  "we" 

•  Use  simple  subject- verb-object  sentences.  Avoid  introductory  adverbial  clauses  unless 
the  content  of  the  clause  requires  special  emphasis.  For  example: 

The  force  is  4  when  the  mass  is  2. 

•  Define  a  new  term  the  first  time  it  appears  in  the  unit 

•  Use  terms  and  definitions  consistently  throughout  the  course.  If  several  terms  can  be 
used  interchangeably,  choose  one  and  stick  with  it.  List  synonyms  when  you  introduce 
and  define  that  term. 

•  Compound  adjectives  are  hypenated  when  the  first  adjective  modifies  the  second 
adjective  and  both  preceed  the  noun: 

A  red-clay  brick  (a  brick  made  of  red  clay)  is  not  the  same  as  a  red,  clay  brick  (a  green 
brick  that  is  painted  red) 

•  Avoid  slang  and  jargon 

•  Avoid  or  "in  other  words,"  or  "and  so  on" 

•  Do  not  use  contractions.  Wnte  "cannot"  instead  of  "can't" 

•  Use  the  indicative  mood  to  show  a  fact.  For  example: 

2  and  2  are  4 

•  Use  the  subjunctive  to  show  something  that  may  or  may  not  happen.  For  example: 

If  2  and  2  were  5 

•  Like/As 

Use  "like"  before  a  noun  or  pronoun.  Use  "as,"  "as  if,"  and  "as  though"  before  phrases 
or  clauses.  For  example: 

This  looks  like  water. 

The  reaction  went  as  it  should. 
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The  electron  behaves  as  if  it  were  a  cloud. 

•  WhichHTiat 

Use  "that"  whenever  the  following  phrase  further  defines  a  subject.  A  "that"  clause 
contains  essential  information  and  is  not  set  off  with  commas.  For  example: 

The  lawn  mower  that  is  broken  is  in  the  garage. 

Use  "which"  whenever  the  phrase  that  follows  contains  supplementary  or  incidental 
information.  "Which"  clauses  are  set  of  by  a  pair  of  commas.  For  example: 

The  lawn  mower,  which  is  broken,  is  in  the  garage. 

If  the  lawn  mower  that  is  broken  is  in  the  garage,  whereas  the  lawn  mower  that  is 
working  is  in  the  yard,  then  the  reader  needs  to  know  that  the  lawn  mower  is  broken  in 
order  to  know  which  of  several  lawn  mowers  is  being  discussed.  The  information  in  the 
clause  restricts  or  limits  the  subject.  Use  "that "  if  the  only  lawn  mower  that  is  in 
question  is  in  the  garage  and,  which  incidentally,  happens  to  be  broken,  use  "which." 


F-54 


Sec  l  ion 


3.7  Graphics 


PHB 


I  10.18 

Presentation  Screen-Horizontal -Bottom 

Unit  name:  Defining  Entities  with  the  DU  I  Unit  No.:  10 

Section:  Conceptual  Overview 


Screen  * :  18 
Section:  1 
Graphics:  N 
Screen  Type:  1 


Border  color:  8 
Speed:  3 
Format:  3 
Columns:  2 
Auto  Advance:  N 
Delay:  0 


Comments : 
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Conceptual  Overview 
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I 


The  Resource,  Item,  Action,  Load,  and  Scenario  entities  will 
be  defined  for  COMMSYS,  which  was  introduced  in  Unit  4. 


<space>  ■  continue  s *  * 


Foreground  Color:  8  Background  Color:  i 

Next  Screen  I:  19 


•  Use  any  graphic  representing  a  particular  system  or  event  consistently  throughout 
the  course 

•  Draw  graphics  neatly 

•  For  the  Final  Detailed  Design  Report,  text  in  graphics  should  be  typewritten,  not 
handwritten 

•  Use  both  upper-  and  lower-case  letters,  not  all  upper-case 

•  Use  the  following  text  margins  on  screens  with  graphics: 
left  -  Space  10 

right-Space  70 
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3.8  AISIM  Color  Scheme  Conventions 

Use  the  following  color  scheme  conventions  for  all  "About  AISIM"  screens.  (These 
combinations  were  chosen  for  optimal  legibility  by  a  group  of  viewers.) 


3.8.1  Text 

All  screens  with  text  should  have: 

•  Bright  white  foreground 

•  Dark  black  background 


3.8.2  Color  Border 

Each  unit  section  is  color-coded.  Every  screen  in  any  given  section  has  the  same  border 
color.  Each  section  of  a  typical  "About  AISIM"  unit  is  listed  below,  followed  by  the  color  assigned 
to  it.  The  number  represents  the  authoring  system's  code  for  each  color  available  in  the  system. 
Note  that  we  assigned  blue  and  green  to  two  sections. 


Section 

Color 

Code  Number 

Opening  screens  (up  to  the  unit  menu) 

Blue 

2 

Menu 

White 

8 

Conceptual  Overview 

Green 

3 

Applying  the  Concepts 

Brown 

7 

COMMSYS  Example 

Blue 

2 

Unit  Summary 

Green 

3 

Self-test 

Magenta 

6 

Exit 

Red 

5 
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3.8.3  Highlighting 


Based  on  the  group's  review,  use  yellow  for  all  highlighting  in  graphics. 
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Appendix  G 

Figure  1-3  from  AFP  50-58,  Volume  I 


This  figure  has  been  referenced  throughout  the  ESD  Prototype  Methodology. 
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